commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@btopenworld.com>
Subject Re: [collections] BidiMap / DoubleOrderedMap
Date Sat, 20 Sep 2003 20:50:18 GMT
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" <heuermh@acm.org>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Cc: <Dave@JungleMoss.com>; <David.Oxley@workplace-systems.plc.uk>
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: commons-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> > >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> 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