[concurrency-interest] jsr166y.forkjoin API comments

Kasper Nielsen kasper at kav.dk
Fri Jan 25 05:37:11 EST 2008


Doug Lea wrote:
> David J. Biesack wrote:
>> Been working with the API more and I have a few more comments/suggestions
>> assembled.
> 
> Thanks! These are great! Please keep them coming! I hope to do
> another renaming etc pass sometime based on the already good
> suggestions stemming from last one.
> 
> Along these lines: We've been thinking of
> separating these from base FJ support and placing in new
> subpackage java.util.concurrent.forkjoin.collections.
> (or for now jsr166y.forkjoin.collections). Any opinions?

Sure, go for it. I think once ParallelMap and ParallelBigArray arrives 
it would make sense.

> 
>> I find createFromCopy and createWithHandoff method names to be awkward; 
> 
>> ParallelDoubleArray pa; pa = ParallelDoubleArray.withCopy(myArray,
>> myForkJoinExecutor); 
> 
> I agree about the problem; hopefully we'll find a nicer solution.

I would prefer plain vanilla createFrom() over createWithHandoff(). I 
think handoff really doesn't make sense for most people with English as 
a secondary language.


>> Rename CommonOps.compoundOp as CommonOps.compositeOp as per the well-known
>> Composite design pattern.
>>
>> Rename the withBounds/withMapping/withFilter methods to simpler bound(...),
>> map(...), and filter(...).
> 
> Or I think a little better: bounding(l,h), filtering(pred), mapping(op).
> I think we'll do this.

I must admit I really like fluent interfaces and the withThis and 
withThat syntax. I think this paper sums up most of the benefits of 
using fluent interfaces like this 
http://www.mockobjects.com/files/evolving_an_edsl.ooplsa2006.pdf
I also remember martin fowler, writing something about the fluent 
interface api style.

> 
>> Having used this a while, I personally don't like the liberal use of
>> "withThis" this and "withThat" throughout the API;
> 
> (Well, except for your suggested use in factories above :-)
> 
>   it makes it more verbose
>> without really adding much. As per Kent Beck's recommendations
>> (Implementation Patterns, p. 24, Qualified Subclass Name: "Prepend one or
>> more qualifiers to the superclass name to form a subclass name"), rename the
>> resulting ParallelArray*WithBounds, *WithMapping, WithFilter to
>> BoundedParallel*Array, MappedParallel*Array, FilteredParallel*Array. I
>> realize these are not subclasses, but conceptually, they are derivations of
>> Parallel*Array.
>>
>> FilteredParallelDoubleArray pa = a.filter(myIndexFilter);
> 
> Note that it should be very rare to give a name to (thus mention the
> type of) to this kind of expression though.
I agree.

-Kasper


More information about the Concurrency-interest mailing list