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 19:44:59 GMT
----- Original Message -----
From: "__matthewHawthorne" <matth@phreaker.net>
> I was thinking that the inverseBidiMap() would just return a reference
> to an inner class which is held inside of the BidiMap implementation.
This is still another object. Sure it can be cached and the same one
returned each time (as per other collections views) but its still annoying

> It all depends on whether we want to be able to call the shortcuts:
> get(value)
> remove(value)
They have to be:
> > getKey(value)
> > removeKey(value)
as BidiMap extends Map

> instead of:
> inverseBidiMap().get(value)
> inverseBidiMap().remove(value)
>
> Since BidiMap is an interface, I would suggest against creating the
> shortcut methods, since it forces all implementations to write them.  If
> we have an abstract implemenation which takes care of it then it's not
> such a hassle.
I reckon that these two shortcut methods cover 80% of the functionality
required (80:20 rule :-0). The rest can go via inverseBidiMap().

> I'd be happy to help out either way.
Grins :-))  I'll checkin a BidiMap interface tonight and we can take it from
there.

Stephen


> Stephen Colebourne wrote:
> > I had an inverseBidiMap() to cover the valueMap() case. However I reckon
> > that since the whole reason for the class is to allow the reverse
lookup,
> > its not unreasonable to be able to access it directly. Having to go via
an
> > inverseBidiMap() method means creating another object, which is quite a
> > large overhead for these operations (well the get at least).
> >
> > Maybe we should have just
> > inverseBidiMap()
> > getKey(value)
> > removeKey(value)
> >
> > The rest could go via the inverse. Maybe.
> > Stephen
> >
> > ----- Original Message -----
> > From: "__matthewHawthorne" <matth@phreaker.net>
> > To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
> > Sent: Saturday, September 20, 2003 6:57 PM
> > Subject: Re: [collections] BidiMap / DoubleOrderedMap
> >
> >
> >
> >>In BidiMap, instead of:
> >>
> >>
> >>>Object getKeyForValue(Object value)
> >>>Object removeValue(Object value)
> >>>Set entrySetByValue()
> >>>Set keySetByValue()
> >>>Collection valuesByValue()
> >>
> >>What about just providing a single method which would return a Map with
> >>the keys/values reversed, such as:
> >>
> >>Map valueMap()
> >>
> >>It would remove the duplication of having to write all these XXXbyValue
> >>methods.
> >>
> >>
> >>Similarly, in SortedBidiMap, instead of:
> >>
> >>
> >>>subMapByValue()
> >>>headMapByValue()
> >>>tailMapByValue()
> >>
> >>what about (I'm not exactly sure what the return type should be):
> >>
> >>Map/SortedMap/BidiMap/SortedBidiMap valueMap()
> >>
> >>
> >>I haven't looked at the existing code, but I suspect that this way would
> >>be easier to write, less lines of code, and more OO.
> >>
> >>What do you think?
> >>
> >>
> >>
> >>
> >>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.
> >>>
> >>>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.
> >>>
> >>>BidiMap
> >>>----------
> >>>Map methods +
> >>>BidiMap inverseBidiMap()
> >>>Object getKeyForValue(Object value)
> >>>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.
> >>>
> >>>An alternative implementation of BidiMap would then be needed, which
> >
> > would
> >
> >>>be useful as it would not require objects to be comparable.
> >>>
> >>>With these new interfaces, decorators could then be written as
required.
> >>>
> >>>Anything obvious I've missed? Any volunteers?
> >>>
> >>>Stephen
> >>
> >>
> >>
> >>---------------------------------------------------------------------
> >>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