[concurrency-interest] Concurrency-interest Digest, Vol 36, Issue 11
forax at univ-mlv.fr
Mon Jan 7 18:50:52 EST 2008
Doug Lea a écrit :
> David J. Biesack wrote:
>> for(T e: pa.withFilter(p1).withFilter(p2).withMapping(m1).sequentially()) ...
> Good idea!
> (Slightly relatedly: Does anyone who uses any of those filtering
> iterator frameworks out there have an opinion about how this meshes with
> them. Using a ParallelArray for such purposes, without ever actually
> triggering parallel computations becomes an unexpected application.)
>> I also have some general comments on the class/interface naming conventions,
> Thanks. You are right that these need to be more regular.
> But I don't know a consistent scheme that also keeps most names short
> and readable, especially given all the wildcard clutter.
> I started with a scheme like the one you suggest, but then decided
> that no one wants to look at a declaration:
> TToUMapper<? super T, ? extends U?>
> The current Mapper<? super T, ? extends U?> is bad enough as it is :-)
> Does anyone have any other ideas that at least arrange that the most common
> types are reasonably pleasant to use?
> Neal Gafter's proposal for functional types helps in some cases,
> but others like "DoubleReducer" and "DoubleComparator" seem both
> more informative and more readable than functional versions:
> "double, double => double", "double, double => int". Hopefully
> someone will come up with a best of both worlds compromise.
> In any case, for present purposes, I'm trying to stay out of
> the language issues, and to make something that people can and
> will get experience using now, not just down the road in Java7.
> All suggestions for helping to get the type names more usable so people
> aren't so scared off from this are welcome.
Why not using internal classes for all specialized types like
Reducer.Double, Reducer.Long, etc.
and Comparator.Double, Comparator.Int, etc.
More information about the Concurrency-interest