groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <>
Subject Re: intersect() returns duplicate elements
Date Thu, 11 Jun 2015 14:36:00 GMT
Am 11.06.2015 14:32, schrieb Peter Ledbrook:
>     If I define intersect like this:
>     A intersect B = C:
>     x element of A and x element of B is equivalent to x element of C
>     with A,B,C not being Sets, just similar, then I don't see why repetition
>     should not be allowed in the result. If somebody wants no repetition,
>     then he should use sets or unique.
> I have a different take on this. I think intersect() is by definition a
> set operation and the method on Iterable is simply a convenience that
> automatically converts the object and the arguments to sets. I would
> even argue for the result of the method always being a set as well.

If you argue like that I have to ask: Does it make sense to convert an 
Iterable to Set automatically? Wouldn't it be better to instead have it 
on Set only?

> Even if one doesn't agree with this definition, the current
> implementation is broken. Surely intersect() must be a commutative
> operation? And yet this code
>      def a = [1, 1, 2, 4]
>      def b = [1, 2, 2, 3]
>      a.intersect(b)
> produces a result of [1, 2, 2]. b.intersect(a) produces [1, 1, 2].

you are right:

I tried using the history of the method to find out why it was added 
this way, but this code goes back to 2003, and I really never talked to 
the author of this method. I did see that the early version did use a 
TreeSet in some cases, but not in all cases.

I really wonder if we should keep the method on anything that is no 
Set... actually even with sets... If a non-standard comparator is used, 
problems like above will easily happen again.

My feeling is that this was added to Collection (now Iterable I know, 
but back then Collection), because there is no native construct for sets.

bye blackdrag

Jochen "blackdrag" Theodorou

View raw message