You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Michael Heuer <he...@acm.org> on 2004/05/04 01:06:25 UTC

[collections] KeySetMap?

Hello,

I need an implementation of Map that uses a predefined set of keys as its
keySet.  Changes made to the set of keys should be reflected in the map's
keySet but not the other way around, e.g. map.keySet() should be
unmodifiable.

I've written something using a wrapped map but I'm having trouble
specifying all of the desired behavior.  For instance, if the size of
the keySet is > 0 but no mappings exist, what is the size of the map?
Would the entrySet view contain entries containing each key mapped to
null?  What should map.remove(key) do?  etc.

Any comments are appreciated.

   michael


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


Re: [collections] KeySetMap?

Posted by Stephen Colebourne <sc...@btopenworld.com>.
This would be a very unusual map implementation (I can't figure out what
your keys might be, and thus why you wouldn't use a Set or Bag).

What you describe is a FixedSizeMap with the exception that keys can be
added via the keySet(). This is a violaton of keySet() (which states that
add is not supported), but an acceptable violation.

An alternative way to view this is that the set of keys that controls the
map is not the keySet(). ie. provide another method, controlKeySet(), to
access that set.

One more alternative - create a small holder class that holds your key and
value (like Map Entry), but where the equals and hashCode is derived only
from the key. Then just use a Set (instead of a map) where each entry is
this new holder class.

Stephen

From: "Michael Heuer" <he...@acm.org>
> On Tue, 4 May 2004, Stephen Colebourne wrote:
> > This sounds more like a map that validates whether its keys are in a
> > predetermined Set. That way, the map would operate as normal, size is
size
> > of mappings, cannot add to keySet but can remove etc.
>
> Right, but that is only part of it.  I would like to support
>
> Set keys = ...{ "foo", "bar" };
> Map map = new KeySetMap(keys);
>
> map.put("foo", 1);
> assert(map.containsKey("foo") == true);
> assert(map.get("foo") == 1);
>
> keys.remove("foo");
> assert(map.containsKey("foo") == false);
> assert(map.get("foo") == null);
>
> keys.add("baz");
> assert(map.containsKey("baz") == true);
> assert(map.get("baz") == null);
>
> but not any of
>
> map.remove("foo");
> map.keySet().remove("foo");
> map.keySet().iterator() ... remove();
> map.put("not a key in keys", 0);
>
> I thought it may be possible to implement this without breaking the Map
> interface contract (by throwing UnsupportedOperationException where
> appropriate), but I'm not so sure.
>
>    michael
>
>
> ---------------------------------------------------------------------
> 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


Re: [collections] KeySetMap?

Posted by Michael Heuer <he...@acm.org>.
On Tue, 4 May 2004, Stephen Colebourne wrote:

> This sounds more like a map that validates whether its keys are in a
> predetermined Set. That way, the map would operate as normal, size is size
> of mappings, cannot add to keySet but can remove etc.

Right, but that is only part of it.  I would like to support

Set keys = ...{ "foo", "bar" };
Map map = new KeySetMap(keys);

map.put("foo", 1);
assert(map.containsKey("foo") == true);
assert(map.get("foo") == 1);

keys.remove("foo");
assert(map.containsKey("foo") == false);
assert(map.get("foo") == null);

keys.add("baz");
assert(map.containsKey("baz") == true);
assert(map.get("baz") == null);

but not any of

map.remove("foo");
map.keySet().remove("foo");
map.keySet().iterator() ... remove();
map.put("not a key in keys", 0);

I thought it may be possible to implement this without breaking the Map
interface contract (by throwing UnsupportedOperationException where
appropriate), but I'm not so sure.

   michael


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


Re: [collections] KeySetMap?

Posted by Stephen Colebourne <sc...@btopenworld.com>.
This sounds more like a map that validates whether its keys are in a
predetermined Set. That way, the map would operate as normal, size is size
of mappings, cannot add to keySet but can remove etc.

The main idea is to separate the validation Set from the actual keySet. This
is now really easy to achieve as I checked in the
AbstractInputCheckedMapDecorator today, which allows validation to be easily
performed (see checkPutKey). Or use AbstractHashedMap if you don't want to
decorate (see addMapping).

Stephen

----- Original Message -----
From: "Michael Heuer" <he...@acm.org>
> I need an implementation of Map that uses a predefined set of keys as its
> keySet.  Changes made to the set of keys should be reflected in the map's
> keySet but not the other way around, e.g. map.keySet() should be
> unmodifiable.
>
> I've written something using a wrapped map but I'm having trouble
> specifying all of the desired behavior.  For instance, if the size of
> the keySet is > 0 but no mappings exist, what is the size of the map?
> Would the entrySet view contain entries containing each key mapped to
> null?  What should map.remove(key) do?  etc.
>
> Any comments are appreciated.
>
>    michael
>
>
> ---------------------------------------------------------------------
> 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