Extension methods and API evolution

[Patrick Wright]

Hi

I'd like to restate a comment regarding declaration-site extension
methods that I posted to Peter Ahé's blog when he suggested them a
couple of years ago
(http://digital-sushi.org/entry/declaration-site-extension-methods/).

Use-site extension methods have the advantage that the extension
methods are not necessarily part of the JDK. In the SMP as I read it,
the java.util.Set interface must be updated, then closed for further
updates until the next JDK release. With use-site extension methods, I
can attach any method to Set that I want, for any project that I work
on. Obviously there will be some methods that the core-libs dev team
decides will be generally useful, though as the discussion around
“humane” APIs some time back showed, it will be hard to agree on what
the limited set should comprise (see
http://martinfowler.com/bliki/HumaneInterface.html). And no one else
will be able to add extension methods to the core API, and they will
remain unchanged (as they are part of the JDK API set) until the next
rev of the JDK. That seems overly constraining.

What I like about use-site extension methods is that we can package
different utility classes with extension methods for lists (or
strings-does this need to be limited to extending interfaces? what
about final classes?), to make them more convenient/friendly to use,
in particular in cases where we run up against the limitations of the
class API–for example, if doing a lot of String manipulation in one
section of our code, we may want to add some convenience methods to
simplify and clarify things (like the recent request for rtrim and
ltrim in String), and in those cases we pick the extensions library
that we think fits the best in that particular situation.

I understand the risk of creating "dialects" of code by allowing
use-site extension methods, but I think the alternative is simply too
restrictive.


Regards
Patrick