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 blog: http://blackdragsview.blogspot.com/
