Stephen Colebourne wrote:
The current HashBidiMap implementation will fail in a couple of places I think.
map.iterator().next() returns a Map.Entry. If you call setValue() on the entry it only updates one map, not the inverse.
map.inverseBidiMap().iterator().next() returns a DefaultMapEntry. This should be a real map entry which allows setValue().
Presumably, tests would be needed for these too.
Stephen
----- Original Message ----- From: "Stephen Colebourne" <[EMAIL PROTECTED]> To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]> Sent: Wednesday, September 24, 2003 11:57 PM Subject: Re: [collections] BidiMap / DoubleOrderedMap
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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
