My expectation is that
> map.put("a", "c");
> map.put("b", "c");
will result in a size 1 map (both ways).
Thus a put(key,value) needs to
- inverse.put(value, key) returns oldMapping
- forward.remove(oldMapping)
- forward.put(key, value)
(or some such code...)
An alternative implementation might throw IllegalArgumentException when the
second method is called. (but we don't need to write this implementation in
[collections])
Stephen
----- Original Message -----
From: "Phil Steitz" <[EMAIL PROTECTED]>
To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]>
Sent: Wednesday, September 24, 2003 4:17 PM
Subject: Re: [collections] BidiMap / DoubleOrderedMap
> __matthewHawthorne wrote:
> > I just committed an initial version of HashBidiMap, the unordered
> > BidiMap implementation.
> >
> > I wrote a fair amount of tests, and everything seems OK, but I would
> > appreciate it if somebody could take a look and let me know what they
> > think, before I start on the ordered version, TreeBidiMap.
> >
> > It was sort of confusing to write and I'm paranoid that I missed
> > something. Thanks!
> >
>
> I like the approach. I am still a bit concerned about the contract vis
> a vis duplicates (not necessarily that it is wrong, but really that I
> don't know exactly what it is). Right now, HashBidiMap will happily
accept:
>
> map.put("a", "c");
> map.put("b", "c");
>
> The size() methods on both the map and inverse will return 2, but the
> inverse really has only one entry <c, b>. Both map.get("a") and
> map.get("b") return "c"; but map.getKey("c") returns "b".
>
> The question is, is this a happy state? This is what I was trying to
> express in the garbled stuff above. This really comes down to specifying
> exactly what the contract of a BidiMap is. The simplest contract (IMHO)
> would require that the map be 1-1, in which case it would probably be
> most natural to have the second assignment above overwrite *both* maps.
>
> If we don't add that requirement and insertion test, it seems to me that
> the contract is going to have to refer to *two* maps and the
> relationship between them is not necessarily what would (at least in the
> mathematical sense) be described as "inverse", since the range of the
> inverse map may end up being a subset of the domain of the original (as
> in case above). We would also have to find a way to get size()
> correctly overloaded to give the actual size of the inverse map (now it
> returns the size of the "forward" map).
>
> 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]
