Extension methods and API evolution

[Patrick Wright]

> I understand your view, but I can't agree.  One of the primary values
> of the Java language is its inherent readability.  Use-site extension
> methods, like many other oft-requested features (e.g., macros), would
> significantly degrade that value.

I understand that point, and, putting aside use-case extension methods
as a potential solution, think that we will still have a problem. If
extension methods are declaration-site, then java.util.List and
friends will have some methods added to them in JDK 7. These will then
be part of the official JDK API, which means, first, you have until
mid-2010 to get them right, second, you will never be able to change
or remove them, and third, we will all have to wait until 201X to have
any new(er) improved extension methods for those interfaces. It would
seem if this will block any opportunity for exploring improvements,
and distributing those via, e.g. open source projects. Essentially,
for the standard Collections API, we will be adding a special sort of
workaround to allow the interfaces to seem as if it had been extended;
it will avoid the problems with actually modifying the interfaces in
question, but will not allow for "real" evolution outside of the JDK
release cycle. This seems too constraining. Evolution involves trial
and error over time.

I think what no one wants are magic extensions which appear in the
code without any choice on the part of the programmer, and are not
obvious from the source. But if there were some way to (waving hands
vaguely) to declare in the imports "...and extend List with
BetterReduceMethods" then that would not be an issue.

Perhaps I'm missing some way to reconcile this...


Regards
Patrick

Regards
Patrick