If col1 and col2 both have the (equally) same 5 objects in common with
set 1 and 2, I would expect set1.equals(set2) to return true, otherwise,
I would expect them only to be of the same size.
I think it is not so much about interfaces, but more about contracts.
Not everything about a contract can always be expressed in interfaces.
Johan Compagner wrote:
they are not the same (and yes talking about java)
And yes removeAll() and remove() are just working and implemented
More stranger thing is
Set set1 = aSetWithSize10;
Set set1 = aSetWithSize10; // different instance, same kind of set same
values
Collection col1 = aCollectionWithSize5;
Collection col2 = aCollectionWithSize15;
col1 and col2 both have 5 objects that are also in the set1,2, and the rest
is just random other stuff
now
set1.removeAll(col1)
set2.removeAll(col2)
now is set1.equals(set2) ?? (or are the sizes the same)
johan
On Wed, Mar 4, 2009 at 02:41, jWeekend <[email protected]> wrote:
Johan,
The question is phrased in such an ambiguous way that it's not even clear
if
you're using Java!
If your col1 and set1 refer to the same object then your "foreach" is not
going to get very far (concurrent modification) so I'll assume that col1
!= set1 .
From a non-functional perspective (acceptable performance, for instance), a
smart implementation of removeAll may loop around the smaller of the two
collections, unlike your "foreach". Now that may seem irrelevant, but if
col1 is a hashed (and well hashed) the removeAll may finish in an
acceptable
timeframe if it is an optimised implementation whereas your for loop code
could go on for longer (potentially, unacceptably long).
Functionally, the first problem you face is that both remove and removeAll
are "optional", so either one, or even both of your snippets may just throw
an exception at you. If they both throw the same exception, I suppose you
may even argue that your 2 snippets are functionally the same for those
implementations of the two collections! If only one throws an
UnsupportedOperationException then they are not equivalent.
The question of the Set being sorted or not is also interesting, but may be
a red herring if remove and removeAll are implemented consistently (but
they
may not be). If the elements of your collections are Comparables, then "it
is recommended but not strictly required" that (x.compareTo(y)==0) ==
(x.equals(y)). Comparator's compare method contract is similarly loose.
Put this in your test case:
public void testComparingEquals(){
BigDecimal onePointOh = new BigDecimal("1.0");
BigDecimal onePointOhOh = new BigDecimal("1.00");
assertEquals(0, onePointOh.compareTo(onePointOhOh));
assertFalse(onePointOh.equals(onePointOhOh));
}
... yes, it passes!
That means that you could have elements of the same type in both your
collections and still get a different result from each of your two snippets
depending on the Comparator passed in to a sorted collection referred to by
set1.
I think there may be more stuff that can go wrong here, but let's see where
this thread heads off to!
Regards - Cemal
http://jWeekend.com jWeekend
Johan Compagner wrote:
Is this the same?
Set set1 = xxx
Collection col1 = xxx;
foreach (col in col1)
set1.remove(col)
or
set1.removeAll(col1);
???
--
View this message in context:
http://www.nabble.com/a-bit-of-topic-but-i-couldnt-resist-....-tp22319709p22321977.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
