interface MapA extends Map {
MapIterator mapIterator();
}
class HashMapA implements MapA {
...
protected int getHashCode(Object obj) {
return obj.hashCode();
}
protected boolean isEqual(Object obj1, Object obj2) {
return obj1.equals(obj2);
}
}
put will use getHashCode() to obtain the hash to store the data under. For
case insensitive, it would return a case insensitive hash value. get will
also use getHashCode() to get the same hash value, and then isEqual() to
compare the keys.
The effect is to allow the hashCode and equals methods on a class to be
replaced. Use cases - case insensitive and identity (==) matching.
The map iterator is separate, but needs doing anyway - thats why I mentioned
it.
Stephen
----- Original Message -----
From: "Phil Steitz" <[EMAIL PROTECTED]>
> Stephen Colebourne wrote:
> > 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]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
