commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz" <p...@steitz.com>
Subject Re: [collections] BidiMap / DoubleOrderedMap
Date Sat, 20 Sep 2003 19:47:04 GMT
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.

> 
> 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 




Mime
View raw message