I would like to propose an alternative solution to the problem that IMO fits well with current [collections] direction.
Consider a new Map implementation that acts as a direct replacement for HashMap, call it HashMapA (A for apache ;-). This class contains basically the same code as HashMap, although it must be written without using cut and paste (ie from scratch - Sun licence issues).
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.
Finally, there would probably need to be a MapA interface to allow access to
the map iterator.
I see this more like Janek does -- the CaseInsensitiveHashMap requirement is really a key transformation requirement, not a hashing algorithm overriding requirement. I think that it would be *much harder* for users of this class to develop well-performing (and reliable) custom hash functions than to supply key transformations. I may be misunderstanding your proposal. Please explain more and why in particular it would not be better to set up something similar to TransformedMap that does key transformations on get -- effectively making a composite map, M o T, where T is the tranformer. The value of this is when T is not 1-1, as in the case of CaseInsensitiveHashMap.
Phil
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
