Re-2: hg: lambda/collections/jdk: 2 new changesets

Wed Feb 23 08:13:48 PST 2011

Hi and thanks for the reply and the explanation of course =)

One short response:
The mail was not meant as a comment to an assumed "perfect and final" state. Sorry if it sounded like that.
It was meant as the opposite: I eagerly browsed the first source code i could get my hands an, noticed a familiar "todo" and thought maybe I could give a hint to help in the future process.
If it came across in the wrong way, I simply blame it on the language barrier :-D.

PS: I just can't seem to get it right to answer to the list in a fashion that the system associates my mails to the posting I reply to :-/.
No "Re: " and "Re: " both didn't work so far. Sorry for tearing the threads apart ...
(Mailing lists are suprisingly complicated to use for a "generation forum"-user like me who never used mailing lists before :D)

Subject: Re: hg: lambda/collections/jdk: 2 new changesets (23-Feb-2011 16:55)
From:    Brian Goetz <brian.goetz at oracle.com>

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 filter(Predicate filter)
>
> and it's defender delegate in SerialEagerCollections:
>
> public static Collection filter(Collection collection, Predicate predicate) {
> return filterTo(collection, new ArrayList(), 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 filter)" and ended with a very unsatisfying "new ArrayList()" 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 copyTo(C target, Predicate predicate);
>
> (Collecting 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 there as well, of course)
> This way, the very same method can do the following things:
>
> final ArrayList newPersonList = persons.copyTo(new ArrayList(), myPredicate);
>
> final HashSet newPersonSet = persons.copyTo(new HashSet(), 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
>
>
>

To: brian.goetz at oracle.com
Cc: lambda-dev at openjdk.java.net