commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rodney Waldhoff <rwaldh...@apache.org>
Subject RE: [COLLECTIONS] Some more lobbying for the OrderedSet class
Date Wed, 30 Apr 2003 16:52:41 GMT
Given that limitation, I wonder if we might better off with either:

A) Create a ListSet interface that doesn't implement either List or Set,
but simply Collection, and include methods for exposing either the Set or
List aspect:

interface ListSet extends Collection {
  /**
   * (some custom ListSet.equals contract)
   */
  boolean equals(Object that);

  /**
   * Returns an "view" of this ListSet as a Set.
   * Changes to the returned Set will be reflected
   * in the underlying ListSet.
   */
  Set asSet();

  /**
   * Returns an "view" of this ListSet as a List.
   * Changes to the returned List will be reflected
   * in the underlying ListSet.
   */
  List asList();
}

Where ListSet.asSet().equals() adheres to the Set.equals contract, and
ListSet.asList().equals() adheres to the List.equals contract.

or,

B) Create a ListSet interface that implements only one of List or Set (I'm
guessing List, which might suggest a name like UniqueList, or in the
implements Set case, OrderedSet), and include methods exposing the
alternative aspect:

interface UniqueList extends List {
  /**
   * (same contract as List.equals)
   */
  boolean equals(Object that);

  /**
   * Returns an "view" of this UniqueList as a Set.
   * Changes to the returned Set will be reflected
   * in the underlying UniqueList.
   */
  Set asSet();
}


There may be some option (C) which provides both UniqueList and
OrderedSet as in (B), both implementing ListSet as in (A), but it's not
clear to me if one could do that or not.

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

On Wed, 30 Apr 2003, Rodney Waldhoff wrote:

> 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
>
>

---------------------------------------------------------------------
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