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