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]
