Why do you we need this when we have MultiKeys available -- i.e., what do you gain by using multiple keys instead of a single MultiKey? Sorry if I am being dense here, but I don't understand what disaggregation of the MultiKey is buying us.
Me not being clear. To use MultiKey as keys in the map has an overhead. For every get/contains/remove you have to create a new MultiKey object which is then thrown away once the operation is complete. This was a performance hotspot in some recent testing I did.
With MultiKeyMap the get/containsKey/remove operations do not create the temporary MultiKey object, they query the data directly. put still creates the MultiKey as that is what is actually stored in the hashed map.
Interesting. So you somehow have optimized the comparison operation to see if e.g., <key1, key2> "equals" a MultiKey that you have in the KeySet. Does this create a dependency on the internals of MultiKey that we need to worry about?
In answer to your original question, I guess I would agree with the "odd collections" package placement; though if you look at it the right way (take off glasses, so keys merge into a MultiKey) it really is a map ;-) In fact, if you limit the interface to just take Object[] arrays as keys, it is just a (directly implemented, not decorated) TypedMap. I assume the <key1, key2, key3> stuff here and in MultiKey is also for optimization.
Phil
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
