Something like this would be required, yes. I'm kindof hoping someone will volunteer to write the HashMapA class so we can get this started. For reasons related to the new MapIterator it needs to go into v3.0.
I don't understand exactly what you are looking for here. Can you explain in a little more detail what you mean by the following:
"HashMapA differs from HashMap in that the hashing algorithm and equals comparison methods are dedicated protected methods. It then becomes easy for a subclass to be written that compares keys using case insensitivity (amongst other things). HashMapA would also have a mapIterator() method to access the new map iterator concept."
What exactly are the semantics of put and get in MapA? How do these relate to the equals (presumably among keys) and hashing (presumably for values) functions? For a CaseInsensitiveMap, would MapA end up storing multiple keys for the same value if they were entered separately?
Also, for the CaseInsensitiveMap (equivalence relation) use case, why exactly is this better than just decorating with a key transformer and allowing access to the decorated map (to allow keySet() to have a meaningful reference)?
Finally, why is MapA necessary for "the new MapIterator"?
I don't mean to be argumentative here, I am just not understanding what you are proposing.
Phil
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
