Robustness of the built in associative array

[Nick]

In article <e0169e$25hq$1 at digitaldaemon.com>, Sean Kelly says...
>
>Indeed.  It seems roughly similar to how arrays are handled: in place 
>modifications persist, but anything causing a realloc does not.  But the 
>original should never be rendered unusable.

True. Except that adding an element to an array (when no realloc occurs) does
not change the original either.

>This would also *almost* allow us to get rid of opCmp(Object) and 
>opEquals(Object) in the Object base class, which would be very nice.  I 
>definately do like having built in AAs, but I do find some of the 
>consequences irritating.

Sort of OT, but I've studied the builtin AA code and have come to the conclusion
that opCmp() isn't needed NOW either. In the binary tree implementation that
Walter used, he first compares the hash values, and only if those matches he
calls opCmp(). Since actual hash collisions should be pretty uncommon(*), opCmp
is almost never called(**). In the rare case of a hash collision, one could make
a special case and eg. always place it in the left node.

(*) It is uncommon for decent hash functions. It seems the builtin AA is
optimized to also work with very bad hashers (in which case it approaches a pure
binary tree.) I guess this isn't a bad feature for a generic AA, but it is also
some of the reason why my custom hash map outperformed it (I didn't use btrees
at all.)

(**) Just did a test with an english dictionary of 173528 words and the standard
D string hasher. opCmp() was called 1840 times, slightly over 1%.

Nick