hg: lambda/collections/jdk: 2 new changesets

[Paul Benedict]

The name of SerialEagerCollections is reminiscent of the eager/greedy,
reluctant, and possessive qualifiers in regex -- different algorithms, in
essence. I assumed other algorithms would be following.

On Wed, Feb 23, 2011 at 9:55 AM, Brian Goetz <brian.goetz at oracle.com> wrote:

> You beat me to the part where I explain what these changes actually are
> supposed to be.  What you're seeing is the first end-to-end
> demonstrations of extension methods in action!
>
> For the time being, this repository (lambda-collections) is completely
> experimental.  Do not take anything that happens here as an indication
> of what the APIs (or implementations) are going to look like.  (This is
> the downside of working in the open; everything that gets checked in is
> assumed to be perfect and final; things in this repo are neither and
> won't be for a long time.)
>
> Rather than start with the hard part (parallel/lazy aggregate
> operations), this changeset demonstrates the simplest serial/eager
> collection->collection operations, which is the least interesting (and
> least efficient) corner of the lambda-enabled collections strategy.
>
> The interesting takeaway here is that there is a simple set of JUnit
> test cases that compile with the lambda-enabled compiler and run using
> the bytecode weaver tool that Robert Field has been working on.  This
> represents the first end-to-end demonstration of extension methods
> working in the compiler, libraries, and VM (though the VM is being faked
> out by a build-time weaving tool, which is just an intermediate step,
> useful for refining the defender resolution algorithms before we start
> hacking the VM.)
>
>
> I'll address your entirely valid API design suggestions separately (but
> probably not for a while.)
>
>
> On 2/23/2011 8:15 AM, Thomas Münz, XDEV Software Corp. wrote:
> > If I may:
> > I browsed the source code a little because I'm very interested in how the
> JDK collections will get enhanced for functional programming, internal
> iteration, etc.
> > Background is: I wrote my own collections framework to replace the JDK
> collections (for many reasons of dissatisfaction with what's there, but
> that's not the issue here, of course)
> >
> > I came accross the new Collection method
> > Collection<E>  filter(Predicate<? super E>  filter)
> >
> > and it's defender delegate in SerialEagerCollections:
> >
> > public static<E>  Collection<E>  filter(Collection<E>  collection,
> Predicate<? super E>  predicate) {
> > return filterTo(collection, new ArrayList<E>(), predicate);
> > }
> >
> > and then accross the comment:
> > // Much work remains in the area of choosing the correct type of
> collection to construct.
> >
> >
> > I had the exact same problem when designing the "XCollection" interfaces.
> I started out with the same "filter(Predicate<? super E>  filter)" and ended
> with a very unsatisfying "new ArrayList<E>()" as an implementation detail.
> > To cut a long story short: as fancy as ".filter()" might look, it turned
> out that it is too concrete and the following is much more convenient and
> flexible in practice (seperating concearns more clearly):
> >
> > public<C extends Collecting<? super E>>  C copyTo(C target, Predicate<?
> super E>  predicate);
> >
> > (Collecting<E>  is a simple interface reabstracting the boolean add(E
> element) method to provide more flexibility for my SQL-like
> Collection-querying framework. For JDK collections, one could put
> Collection<? super E>  there as well, of course)
> > This way, the very same method can do the following things:
> >
> > final ArrayList<Person>  newPersonList = persons.copyTo(new
> ArrayList<Person>(), myPredicate);
> >
> > final HashSet<Person>  newPersonSet = persons.copyTo(new
> HashSet<Person>(), myPredicate);
> >
> > persons.copyTo(alreadyExistingTargetCollection, myPredicate)
> >
> > myCollectionFactory.toNewInstance(persons, myPredicate)
> >
> > this.doSomethingElseWith(persons.copyTo(alreadyExistingTargetCollection,
> myPredicate));
> >
> > etc. ...
> >
> > In the end, I found that it's almost never desireable to have a (general
> purpose) collection implementation decide on its own which type of
> collection one has to use in the application code. The filter(predicate)
> variant would be just another method next to copyTo(target, predicate) to
> bloat method count but be of very little use (or even dangerous and thus
> adverse, given that the implementation-decided collection type might change
> silently) compared to it.
> >
> >
> > Don't know if it's bumptious (<- funny word from the translator website)
> to tell the "pros" how to design their interfaces ;), but back then it
> turned out to be cleaner architecture that way for me (although losing the
> fancy "filter()"-like looks :) ), so I just thought throwing it in might
> help.
> > There'd be similar findings regarding collections in general and their
> enhancement towards functional programming, performance, functionality,
> etc., but I guess I'd make myself pretty obnoxious pretty quick once getting
> started :-D (and it'd be off-topic here as well).
> >
> >
> > Regards,
> > Thomas
> >
> >
> >
> > Subject: hg: lambda/collections/jdk: 2 new changesets (Tue Feb 22
> 16:01:45 PST 2011)
> > From: brian.goetz at oracle.com brian.goetz at oracle.com
> >
> >> Changeset: 63693b18adef
> >> Author:    briangoetz
> >> Date:      2011-02-22 19:00 -0500
> >> URL:>
> http://hg.openjdk.java.net/lambda/collections/jdk/rev/63693b18adef
> >>
> >> Add SAM types Block,Predicate,Reducer,Mapper; add simple
> forEach/filter/map/reduce methods to Collection,List,Set with simple
> serial/eager implementations; add simple test suite (1 suppressed failure)
> >>
> >> + defender-tests/build.xml
> >> + defender-tests/src/SerialEagerCollectionsTest.java
> >> ! make/common/shared/Defs-java.gmk
> >> ! make/java/java/FILES_java.gmk
> >> ! src/share/classes/java/util/Collection.java
> >> ! src/share/classes/java/util/List.java
> >> + src/share/classes/java/util/SerialEagerCollections.java
> >> ! src/share/classes/java/util/Set.java
> >> + src/share/classes/java/util/sam/Block.java
> >> + src/share/classes/java/util/sam/Mapper.java
> >> + src/share/classes/java/util/sam/Predicate.java
> >> + src/share/classes/java/util/sam/Reducer.java
> >>
> >> Changeset: f6dceeefc7c4
> >> Author:    briangoetz
> >> Date:      2011-02-22 19:01 -0500
> >> URL:
> http://hg.openjdk.java.net/lambda/collections/jdk/rev/f6dceeefc7c4
> >>
> >> Merge
> >
> >
> >
>
>