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: https://proofwiki.org/wiki/Intersection_is_Commutative
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
blog: http://blackdragsview.blogspot.com/
