commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Arun Thomas" <arun.tho...@paybytouch.com>
Subject RE: [collections] CaseInsensitiveHashMap
Date Tue, 25 Nov 2003 16:38:32 GMT
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:phil@steitz.com] 
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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 




---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message