Whither extension methods?

[Neal Gafter]

I find the described motivation for this whole exercise questionable.
Multicore is certainly important, and the proposed changes do improve
things, but to suggest that every issue must relate to and be decided on the
basis of its impact on multicore doesn't make sense.

Still, extension methods for concurrent aggregate operations can peek at the
implementation of the collections they receive to take advantage of
decomposition facilities where available.  It would therefore be worthwhile
to add interfaces for decomposability and retrofit the collections classes
(not interfaces) to those interfaces.

Even when decomposition is not available, very good speedup can be achieved
when the operation to be done on each element is much more expensive than
moving from one element to the next.

Both extension methods and lambda expressions are required to support more
flexible automatic parallelization of the sort that appears in Microsoft's
PLinq library.  It achieves nearly linear speedup on aggregate operations
over ordinary collections (IEnumerable, actually, which is the equivalent of
Iterable) without needing to introduce a separate set of APIs.  It is more
flexible than ParallelArray in that it allows the operations to be chained,
and aggregates the operations per element.  But to do that, you need to add
support for tree lambdas.  That could be done as a separate extension later;
it doesn't have to be done all at once.

Cheers,
Neal

On Mon, Dec 14, 2009 at 11:46 PM, Joshua Bloch <jjb at google.com> wrote:

> Doug Lea sent this a couple of days ago, and I think it deserves our
> consideration:
>
> I confess to being a little confused about the rationale for extension
> > methods.
>
>
> > 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?
>
>
> > You might want to read Guy Steele's nice talk on related issues at
> >
> http://groups.csail.mit.edu/mac/users/gjs/6.945/readings/MITApril2009Steele.pdf
>
>
> > -Doug
>
>