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 Tue, 16 Jun 2015 04:14:01 GMT
Am 16.06.2015 00:25, schrieb Paul King:
> I don't necessarily think the existing name is necessarily that bad.
> It follows the general definition of the word intersection as per
> wikipedia - just not the more specialized set intersection defn.

the trouble is that it confuses people... intersect can have a wide 
variety of meanings. For example if I intersect two circles I might get 
back a shape, that is no circle anymore. But most important here is of 
course the meaning of an intersection of two lists. And here the 
tendency to see the lists like sets is high imho.

> Having said that, I'd have no problem with something that improves
> things without creating further confusion. Are we looking for names
> for the existing method or for a set-based one? findAll works for
> me as a replacement/parallel name - we just don't want to create
> confusion with the existing mutating retainAll. Also, something
> like strictIntersect might work for a Set based variant.

I was thinking of having Collection#findAll(Collection):Collection, 
which does what intersect does atm. Then deprecate intersect on 
everything but Set, plus a variant on SortedSet, which will check the 
comperators before delegating to the general variant, or do something 
special, since you can use the SortedSet for a faster algorithm.

> There are many examples of Groovy methods which aren't commutative.
> The fact we have left.operation(right) has an implication that
> left and right might play different roles. We try to reduce the times
> when lack of commutativity causes confusion and that most frequently
> means methods which map to operators and names like intersect
> would be a close second as to when confusion can arise but it doesn't
> mean we have to always have commutativity.

findAll(Collection) won't be commutative in general for example. sure. 
but I think we should try to avoid "mathematical terms" in such cases.

bye blackdrag

Jochen "blackdrag" Theodorou

View raw message