Whither extension methods?
mr at sun.com
Thu Dec 17 21:43:33 PST 2009
> Date: Mon, 14 Dec 2009 23:46:38 -0800
> From: Joshua Bloch <jjb at google.com>
> Doug Lea sent this a couple of days ago, and I think it deserves our
>> I confess to being a little confused about the rationale for extension
>> Suppose we have a Map, and want to some sort of apply-to-each-value
>> operation. The only reasonable way to do this in parallel is to somehow
>> splitthe work. But Map has no public methods allowing you to do this -- you
>> can only get an iterator, which is inherently sequential. Now, if we
>> could get at the representations, then we could actually do splits for most
>> java.util maps (at least for the most common ones -- HashMaps, TreeMaps). So
>> the only way I know for these to be bolted on is to introduce new interfaces
>> that each of the these existing classes could be changed to implement. Or am
>> I missing something?
The rationale for extension methods (or something like them) is to allow
lambda expressions to be used to express sequential computations upon
instances of the existing collection classes, in much the same manner as
will be possible with parallel arrays, without the need to cast such
instances to some new, specialized type.
This rationale doesn't take into account the possibility of implementing
these bulk-data operations automagically in parallel when appropriate.
I agree that's something worth exploring, and I realize that the outcome
could be another argument against adding extension methods in the first
More information about the lambda-dev