commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@btopenworld.com>
Subject Re: [collections] MultiKeyMap
Date Fri, 30 Apr 2004 23:56:12 GMT
I have refactored MultiKeyMap to be a decorator instead of an
implementation. This gives many more possibilities without needing to code
extra classes (saving space ;-).

This decorator is different however in that it doesn't use the public Map
API. Instead it uses the protected parts of the AbstractHashedMap. Thus
MultiKeyMap cannot decorate a HashMap, but can decorate a HashedMap.

Even so, it now means that you can have an LRU, Linked or Reference
MultiKeyMap without any additional effort.

Anyone object to decorating in this way?

Stephen

----- Original Message -----
From: "Stephen Colebourne" <scolebourne@btopenworld.com>
> I have now checked in the map and test into the map subpackage.
>
> After further thought, it would be nice to create a new subpackage for
this
> class, and for MultiValueMaps. It requires a new interface for
MultiValueMap
> and MultiKeyMap, plus a rewrite of the MultiHashMap implementation, moving
> MultiKeyMap, and creating synchronized decorators. This might take some
> time, but is the correct solution :-0 Its needed because MultiKeyMap will
> often need to be synchronized.
>
> Stephen
>
> ----- Original Message -----
> From: "Stephen Colebourne" <scolebourne@btopenworld.com>
> > I am currently developing a MultiKeyMap for [collections]. This class
> > operates like a Map, but has multiple keys instead of one.
> > get(key1, key2, key3)
> > put(key1, key2, key3, value)
> > (choice of 2-5 keys as per MultiKey)
> >
> > I have made the class implement Map, however no-one will want to ever
use
> it
> > as a Map (ie. hold it in a Map variable). So, I could
> >
> > 1) Place the class in the map subpackage, because its map-like
> >
> > 2) Place the class in the main package, alongside MultiMap (the multi
> value
> > map)
> >
> > 3) Create a new subpackage, together with a new interface
> >
> > #3 seems like a lot of work, especially as we have little evidence of
what
> > the interface really needs to be. #1 would make sense, except that every
> > other class in the map subpackage truly is a map. So I'm tending towards
> #2,
> > to join ArrayStack, BeanMap and MultiHashMap as the weird collections
;-)
> >
> > Any other views?
> >
> > Stephen
> >
> >
> > ---------------------------------------------------------------------
> > 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