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