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