hg: lambda/lambda/jdk: initial small set of extension methods on Collection and List which provide functional-style variants of common operations.
Neal Gafter
neal at gafter.com
Fri Aug 19 09:36:38 PDT 2011
Right. I was suggesting an organization for the code of the APIs. That was
only an example, and will depend on the actual syntax chosen.
On Fri, Aug 19, 2011 at 9:33 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
> Sorry, we don't discuss syntax here.
>
>
> On 8/19/2011 12:26 PM, Neal Gafter wrote:
>
>> On Thu, Aug 18, 2011 at 3:47 PM, Mike Duigou<mike.duigou at oracle.com>
>> wrote:
>>
>> Hi Paul, the real name of these classes is garbage class.
>>>> But ListGarbage is not that cool :)
>>>>
>>>> As Mike says, it's just the first cut, I really hope we will not
>>>> have any of these classes at all at the end.
>>>>
>>>
>>> Where do you advocate that they should go? For the collection extensions
>>> the obvious location is Collections. Should we just create parallel
>>> classes
>>> for List, Set, Map, etc? ie. Lists, Sets, Maps, etc.
>>>
>>>
>> They should go in the interface. For example:
>>
>> public interface Collection ... {
>> ...
>>
>> /**
>> * Retains all of the elements of this collection which match the
>> provided
>> * predicate.
>> *
>> * @param filter a predicate which returns {@code true} for elements to
>> be
>> * retained.
>> * @return {@code true} if any elements were retained.
>> */
>> // XXX potential source incompatibility with retainAll(null) now being
>> ambiguous
>> boolean retainAll(Predicate<? super E> filter) {
>> boolean retained = false;
>> Iterator<E> each = this.iterator();
>> while(each.hasNext()) {
>> if(!filter.eval(each.next())) {
>> each.remove();
>> } else {
>> retained = true;
>> }
>> }
>>
>> return retained;
>> }
>>
>> ...
>> }
>>
>>
More information about the lambda-dev
mailing list