From: Alan Chen <alan@...>
Date: 2002-09-21T06:00:59+09:00
Subject: Re: Checking hash key's and values, with case insensitivity

On Sat, Sep 21, 2002 at 04:09:51AM +0900, Philipp Meier wrote:
> On Sat, Sep 21, 2002 at 01:43:10AM +0900, MikkelFJ wrote:
> > 
> > "Dossy" <dossy@panoptic.com> wrote in message
> > news:20020920153223.GZ27665@panoptic.com...
> > 
> > > If you're looking for case insensitive hashes you're already
> > > going to hell.
> > >
> > > Isn't the whole constraint of a hashtable is that it's case sensitive?
> > >
> > > -- Dossy
> > 
> > The way to deal with this is to create a hashtable that is indexed by
> > normalized keys i.e. all uppercase or all lowercase characters. Upon lookup
> > you map the search key the same way. The actual hash lookup is still case
> > sensitive. You may then store the original key as a value and you may also
> > want to maintain two hashes - one with the original keys and one with the
> > normalized keys.
> 
> And do what if you have two keys in the original hash if they are equal
> when ignoring the case?

Overall, if your application code doesn't already expect normalized
hash keys, I think I agree with dossy. :) For this application case
collision on the keys something that needs to be handled regardless of
the storage scheme.  It's just a matter of where you want to handle
before storing the value, or after.

I don't have the earlier posts in the thread, but how was it going to
be handled orginally? For this scheme, 

If you want case insensitive hash keys always, I'd just normalize the keys
before storing the value. Case collisions overwrite the value.

If you want case sensitive on store, and case insensitive on retreive
then you could store an array of the possible matching keys, check for
an array and trigger the same "case collision" logic as in the
original case.

Cheers,
alan
-- 
Alan Chen
Digikata LLC
http://digikata.com