hg: lambda/lambda/jdk: initial small set of extension methods on Collection and List which provide functional-style variants of common operations.
Howard Lovatt
howard.lovatt at gmail.com
Fri Aug 19 18:08:09 PDT 2011
I would suggest putting them as an inner class within the interface, e.g.:
public interface Collection ... {
boolean retainAll( Predicate<? super E> filter ) default Trait.retainAll;
...
static final class Trait {
private Trait() {}
public static boolean retainAll( final Collection self, final
Predicate<? super E> filter ) { ... }
...
}
}
That way everything is in one place, including the JavaDoc.
On 19 August 2011 17:26, Neal Gafter <neal at gafter.com> 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;
> }
>
> ...
> }
>
>
--
-- Howard.
More information about the lambda-dev
mailing list