PRE-PROPOSAL: Extension methods

Neal Gafter neal at gafter.com
Wed Mar 18 14:28:59 PDT 2009


On Wed, Mar 18, 2009 at 2:00 PM, Florian Weimer <fw at deneb.enyo.de> wrote:
>> There are a number of benefits to this approach.  A large number of
>> static utility class members can and probably should be retrofitted to
>> use extension methods, making it possible to use a much more
>> convenient syntax for common operations.
>>
>>     import static java.util.Collections.sort;
>>     List<Integer> list = ...
>>     list.sort(); // uses Collections.sort extension method
>
> (Does this proposal imply import statements?  Would they make sense in
> this context?)

I don't understand this question.  Java already has import statements.

>> One of the more important benefits of this approach is that it enables
>> future language changes to be defined by syntactic translation, while
>> allowing more flexible retrofitting of those language changes onto
>> existing APIs than would be possible without extension methods.
>
> I think the problem here is that you have to figure out which
> class/static method to import to make ARM work.  For a feature like
> ARM, where the main factor is convenience to counter sloppiness (at
> least from my point of view), this seems like a significant burden.  I
> think Reinier is right that this feature alone is insufficient to
> implement proper ARM.

Agreed: in addition, we'd need some small amount of work in the
libraries to *provide* the extension methods in convenient places, and
conventions around what those places should be.  For example,
extension methods for collections would be in Collections, for arrays
they'd be in Arrays, for Closeable they'd be in Closeables, etc.

> Oh, and I wonder how this particular brand of extension method will
> interact with reifed/compile time generics.

I don't see how there could be any issue.  The spec for extension
methods would remain unchanged by the addition of reified generics.
Extension methods are done by a syntactic transformation based on the
static type of the receiver, not its dynamic type.



More information about the coin-dev mailing list