[concurrency-interest] Concurrency-interest Digest, Vol 36, Issue 11

Kasper Nielsen kasper at kav.dk
Mon Jan 7 15:22:06 EST 2008

David J. Biesack wrote:
>> Below is pasted reminder about main changes.
>> Which forgot to mention full cascade support:
>>    pa.withFilter(p1).withFilter(p1).withMapping(m1).withMapping(m2)...
>> (Yes, I did once say that I wasn't going to do this, but decided
>> that people were right about it being very inconvenient to do this
>> manually.)
> Nice; I like the chaining.
>> Also, here are a few questions for those of you using these APIs.
>> 1. It is now easy to use the default global ForkJoinExecutor,
>> but should it be made even easier, by supporting static factory
>> methods that omit it as an argument? 
> I'd prefer to see a smaller API footprint, so I recommend leaving the parameter there rather than overloading, and simply use the default executor if the caller passes null.
Yes I like forcing the user to think just a little bit. So keep it as it 
is. But I don't think null should be used to indicate the default 
executor. It is bad API design in my opinion.

> Taking a hint from Fortress and other such languages with parallel loops, where a parallel loop
>     for (item <- generator)
> becomes sequential with
>     for (item <- sequential(generator))
> could some sort of sequential operator or method be added to achieve the behavior
> of delayed execution of the mappings, i.e. with a FutureTask or something?
>     for(T e: pa.withFilter(p1).withFilter(p2).withMapping(m1).sequentially()) ...

I like it.

> I also have some general comments on the class/interface naming conventions, which differ depending on whether the signature involves a generic type parameter T or not. I don't see a strong reason for the disparity and recommend a consistent naming pattern
>   <FromType>To<ToType>Mapper
>   <Type>Predicate
>   <Type>Comparator
>   To<Type>Generator
>   Mapper
Yup this is important. I still have to look at the javadocs each time I use
TimeUnit.someunit.convert(), because I can't remember if it converts to 
or from the specified TimeUnit. Now if it was named convertFrom it would 
be a lot easier to remember.

> Or, if there is not a strong reason for using T and U generic type names, I suggest T for a "to" type and F for a "from" type, as in

>   Ops.Mapper<F,T>       :: T    map(F from)
>   Ops.Predicate<F>      :: boolean evaluate(F from)
>   Ops.Combiner<F,G,T>   :: T    combine(F f, G g) 

I like the F, T naming scheme and use it myself. I also know that the 
Google collection library uses it.


More information about the Concurrency-interest mailing list