Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Message-ID: <3F6F87C2.4030706@phreaker.net>
Date: Mon, 22 Sep 2003 16:37:38 -0700
From: __matthewHawthorne <matth@phreaker.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.5b) Gecko/20030901 Thunderbird/0.2
MIME-Version: 1.0
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: Re: [collections] BidiMap / DoubleOrderedMap
References: <007d01c37f74$9ca811a0$b7768051@oemcomputer>
 <3F6F6BD7.60305@phreaker.net> <005401c3815f$27dbd360$7a7c8051@oemcomputer>
In-Reply-To: <005401c3815f$27dbd360$7a7c8051@oemcomputer>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

HashBidiMap is fine with me.  My best thought seems to match yours, I'm 
keeping two HashMaps in sync (one the inverse of the other).  I'm trying 
to think of a better way, but I'm drawing a blank.

For now, I'm just concentrating on writing solid tests to make sure the 
interface works... low level improvements can come whenever a better 
idea occurs.


Stephen Colebourne wrote:

> I was thinking of HashBidiMap as I assumed it would involve hashing. (My
> current best thought is two tied HashMaps, but thats not very nice
> really...)
> 
> The main thing with TreeBidiMap is to retain the speed of the specialist
> implementation while adding the new interface ;-)
> 
> Stephen
> 
> ----- Original Message -----
> From: "__matthewHawthorne" <matth@phreaker.net>
> To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
> Sent: Monday, September 22, 2003 10:38 PM
> Subject: Re: [collections] BidiMap / DoubleOrderedMap
> 
> 
> 
>>I've started some work on converting DoubleOrderedMap to TreeBidiMap.
>>
>>What is the suggested name for the basic BidiMap implementation which is
>>n't sorted?  DefaultBidiMap?
>>
>>
>>
>>
>>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
>>