A BidiMap interface has just been checked in as a starter. It has - getKey(Object value) - removeKey(Object value) - inverseBidiMap()
I personally prefer Bidi, because its easier to manage simply from length. I think the name needs to be one word, otherwise implementation names get confusing. And Invertable doesn't work for me. The implementation names are formed by <internalOfImpl><interfaceName> dropping 'Sorted' from the interface name if it is present. 'TreeBidiMap' thus results from the RedBlack Tree implementation + SortedBidiMap name. Stephen ----- Original Message ----- From: "Michael Heuer" <[EMAIL PROTECTED]> To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Saturday, September 20, 2003 9:05 PM Subject: Re: [collections] BidiMap / DoubleOrderedMap > > On Sat, 20 Sep 2003, Phil Steitz wrote: > > > See comments inline. > > > > Stephen Colebourne wrote: > > > I have been prompted to take a look at DoubleOrderedMap by bugzilla and been > > > a little surprised by what I found. Given the history of collections, what > > > we have is a single implementation brought in from an external project. > > > [collections] should do better :-) > > > > > > A bidirectional map is a relatively standard concept in computing. It is a > > > map where you can use a key to find a value, or a value to find a key with > > > equal ease. This deserves its own interface in [collections] - BidiMap. > > > > I agree, though I would favor either spelling out "Bidirectional" or > > using "Invertible" or "OneToOne" as the prefix. Unless the term > > "BidiMap" is a "familiar" term, I would suggest picking a full word for > > the prefix. > > For what it's worth, I would also prefer "Bidirectional" for the prefix. > > michael > > > > > > > > > The DoubleOrderedMap class goes beyond this by being Sorted, effectively > > > holding all entries in a Compared order always. This effectively equates to > > > a second interface in [collections] - SortedBidiMap. > > > > Yes, and it is important to distinguish between what is required by the > > interface and how the implementation happens to work. The current class > > header comments are a bit confusing/nonsensical on this. How things are > > "stored" is irrelevant to the interface. > > > > > > > > BidiMap > > > ---------- > > > Map methods + > > > BidiMap inverseBidiMap() > > > > > Object getKeyForValue(Object value) > > > > Could drop "ForValue" here. > > > > > Object removeValue(Object value) > > > Set entrySetByValue() > > > Set keySetByValue() > > > Collection valuesByValue() > > > > > (these method names are from DoubleOrderedMap, and seem OKish) > > > > > > SortedBidiMap > > > ---------------- > > > BidiMap + SortedMap + > > > inverseSortedBidiMap() > > > subMapByValue() > > > headMapByValue() > > > tailMapByValue() > > > > > > The existing DoubleOrderedMap is an implementation of SortedBidiMap. However > > > I would like to rename it to TreeBidiMap. > > > > InvertibleTreeMap or BidirectionalTreeMap might be better. > > > > > > > > An alternative implementation of BidiMap would then be needed, which would > > > be useful as it would not require objects to be comparable. > > > > +1 > > > > > > > > With these new interfaces, decorators could then be written as required. > > > > > > Anything obvious I've missed? Any volunteers? > > > > > > Stephen > > > > > > > > > > > > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
