[concurrency-interest] Concurrency-interest Digest, Vol 36, Issue 11
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:
>> (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
> 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
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