• Stewart Gordon (31/31) Nov 15 2004 I've noticed that the hashmap template I created a while back only works...

Stewart Gordon <smjg_1998 yahoo.com> writes:

I've noticed that the hashmap template I created a while back only works 
with struct/union/class types and not with primitive/array/pointer types.

Basically, we have a limitation on the generic programming side: the 
.toHash property is only definable on struct/union/class types, and 
doesn't exist on built-in ones.  I cannot change it to dig into 
TypeInfo, since half the point of my template is to be a workaround for 
the failings of D's AAs.  TypeInfo hacking is a rather down and dirty 
approach anyway; even once the shortfalls are dealt with, key.toHash 
will remain a nicer notation than typeid(KeyType).getHash(&key).

The .toHash property would correspond to the existing hash function for 
the relevant type.  The only issue I see is what should happen with 
pointer types.  Possibilities I can see are:

(a) Keep TypeInfo_P.getHash returning the memory address, and have 
pointer.toHash follow this convention.  But this would make an exception 
to the rule that pointer.anything is equivalent to (*pointer).anything.

(b) Redefine the hash of a pointer (except void*) to be equal to the 
hash of the dereferenced data.  Not sure if this would be the Right 
Thing, as any container that uses pointers as keys would be invalidated 
if the data they point to is modified.

(c) Keep the TypeInfo (and hence the behaviour in built-in AAs) as it 
is, but nonetheless have pointer.toHash equivalent to (*pointer).toHash. 
  This wouldn't break existing code, but would require that a given 
template consistently uses either .toHash or TypeInfo.getHash.

And this is before you get back into arguing over the propriety of using 
memory addresses as hash values.

Similarly, every type having a .toString property might be handy, and it 
would correspond to the behaviour of the "%s" format specifier on the 
type involved.  Well, maybe open to the same debates....

Just thinking about it, I guess it's a matter of debate whether these 
features would really achieve anything over fixing some bugs....

Stewart.