Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Date: Wed, 30 Apr 2003 09:37:19 -0700 (PDT)
From: Rodney Waldhoff <rwaldhoff@apache.org>
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: RE: [COLLECTIONS] Some more lobbying for the OrderedSet class
In-Reply-To: 
 <73E71EF16978D51197180002A56022D20743C4E5@ngmnt4mbx03.uk.capitalone.com>
Message-ID: <20030430092832.G57842@icarus.apache.org>
References: 
 <73E71EF16978D51197180002A56022D20743C4E5@ngmnt4mbx03.uk.capitalone.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 30 Apr 2003, Hope, Matthew wrote:

> The contract of the Set.equals() method is conformed to by the List.equals()
> method

But the contract of List.equals is not compatiable with Set.equals, since
List cares about order, but Set does not.

This means that for some ListSet:

  listSet := { 1, 2, 3 }

and a Set

  set := { 3, 2, 1 }

(assume { a, b, c } means that the iterator() method
returns elements in that order).  Assuming ListSet implements Set, then:

  set.equals(listSet)

is true but:

  listSet.equals(set)

is false, which is a violation of the general Object.equals contract.

This limitation is noted in the Collection.equals method documentation,
which reads in part: "it is not possible to write a class that correctly
implements both the Set and List interfaces".

- Rod <http://radio.weblogs.com/0122027/>

>
> Therefore by default using the List implementation is safe
>
> However it would make sense to have the equals method explicityly meaningful
> via:
>
> public boolean equals(Object o)
> {
> 	if (o instanceof ListSet)
> 	{
> 		ListSet otherSet = (ListSet)o;
> 		if (otherSet.size() != size())
> 		{
> 			return false;
> 		}
>
> 		for (int i = 0; i < size(); i++)
> 		{
> 			if (!equalsOrBothNull(get(i), otherSet.get(i)))
> 			{
> 				return false;
> 			}
> 		}
> 		return true;
>
> 	}
> 	return false;
> }
>
> // implement accordingly
> public boolean equalsAccordingToSet(Object o);
> public boolean equalsAccordingToList(Object o);
>
> private boolean equalsOrBothNull(Object o1, Object o2)
> {
> 	if (o1 == null && o2 == null)
> 	{
> 		return true;
> 	}
> 	if (o1 != null)
> 	{
> 		return o1.equals(o2);
> 	}
> 	return o2.equals(01);
> }
>
> Or alternatively just guarantee that any object capable of providing an
> iterator returns all and only all of the objects in this in the same order
> as this...
>
> Matt
>
> -----Original Message-----
> From: Rodney Waldhoff [mailto:rwaldhoff@apache.org]
> Sent: 30 April 2003 16:57
> To: Jakarta Commons Developers List
> Cc: bayard@generationjava.com
> Subject: Re: [COLLECTIONS] Some more lobbying for the OrderedSet class
>
>
> I agree that ListSet is a useful an intuitive concept.  Unfortunately,
> it's not possible to fully and correctly implement both interfaces, by
> nature of the List.equals and Set.equals contracts.  We may want to create
> our own ListSet equality definition, or pick one of List.equals or
> Set.equals as our defintion of ListSet equality, and make that limitation
> very clear in the documentation.  If we do the latter, let's say List,
> then we'll probably want to define a ListSet.equalsSet(Set):boolean
> method and/or a ListSet.toSet():Set method.
>
> - Rod <http://radio.weblogs.com/0122027/>
>
> On Tue, 29 Apr 2003 ericpabst@discoverfinancial.com wrote:
>
> > I strongly agree that a ListSet interface that extends both List and Set
> is
> > the most intuitive way to go.  "List" and "Set" are understood by Java
> > developers anywhere and to have a "ListSet" interface would make it very
> > clear what it means.
> >
> > Eric Pabst
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
> **************************************************************************
> The information transmitted herewith is sensitive information intended only
> for use by the individual or entity to which it is addressed. If the reader
> of this message is not the intended recipient, you are hereby notified that
> any review, retransmission, dissemination, distribution, copying or other
> use of, or taking of any action in reliance upon this information is
> strictly prohibited. If you have received this communication in error,
> please contact the sender and delete the material from your computer.
>
> ---------------------------------------------------------------------
> 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