PRE-PROPOSAL: Extension methods

Florian Weimer fw at deneb.enyo.de
Wed Mar 18 14:00:09 PDT 2009


* Neal Gafter:

> 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?)

> 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.

But it's probably better than annotation trickery I proposed, or
dictating the use of a single interface.

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



More information about the coin-dev mailing list