The issue of recreating the original key is exactly the value behind the process that Stephen proposes. While the proposal leads to a more general solution with the potential complexity of writing good hash functions, it certainly covers simple cases like this - where a transformation is applied to the key, and then the job of generating a hash is delegated to the transformed value (which potentially provides a good mechanism for generating a hashcode).
This allows the data in the HashTable to remain unchanged, while allowing equality to be redefined. -AMT -----Original Message----- From: Phil Steitz [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 25, 2003 7:38 AM To: Jakarta Commons Developers List Subject: Re: [collections] CaseInsensitiveHashMap Phil Steitz wrote: > Stephen Colebourne wrote: > >> 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 > > Thinking about this some more, the semantics of keySet() would be difficult with "CompositeMap" approach that I have suggested above. We would either have to require that T be idempotent - i.e., T(T(x)) = T(x) or have the user supply a (partial) inverse transformer to return *a* pre-image for each transformed key. Phil > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
