Mailing-List: contact dev-help@groovy.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@groovy.incubator.apache.org
Message-ID: <557FA289.8000500@gmx.org>
Date: Tue, 16 Jun 2015 06:14:01 +0200
From: Jochen Theodorou <blackdrag@gmx.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: dev@groovy.incubator.apache.org
Subject: Re: intersect() returns duplicate elements
References: 
 <CANBeYQRcS_5kbJunzYTkaouqrp-b5rWeoW_rpKEEmuG1VFCnug@mail.gmail.com>
 <CAL2qGUFJL7+NT6ZUGtAsGjyW2xy-iB1kAsWiDyCuvB364uZtgw@mail.gmail.com>
 <CAKrRyTAb2=Cut81ZVyHZW5uEAftGZz0t00xScbYMVMEbw=Ezqg@mail.gmail.com>
 <CAL2qGUFrJ4rEUbvY59QXnJfwhU7r8C2K2b+DQA=d=Gnq5FZdjw@mail.gmail.com>
 <CAL2qGUEJD-Qpp3rEgEdqv7BUCNVm1n0M0yc7nUM9iaUQv2y+Bw@mail.gmail.com>
 <5577C0DB.2080207@gmx.org>
 <CAL2qGUHSu3V3jJhgjE94ygrysHU3vfHfSx3ZHW-XocbmpN8dZw@mail.gmail.com>
 <5577E3D9.7050807@gmx.org>
 <CANBeYQSDJd55XH2+n=iKWn2VsWfbygpWfm0eXGao+hKpFrOQew@mail.gmail.com>
 <55799CD0.4000705@gmx.org>
 <CANBeYQQX5OHoo53L43gjeiSTx9Y6w0wjLq2TxLR64c9V8=K4jg@mail.gmail.com>
 <557F2050.5000105@gmx.org> <557F50DA.9010107@asert.com.au>
In-Reply-To: <557F50DA.9010107@asert.com.au>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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/