Extension methods and API evolution

[Patrick Wright]

> Very strange that you seem to value fragmentation over centralization. The
> "useful" higher order functions have been explored for more than ten years
> in languages like haskell, that have no problem with breaking compatibility.
> Your solution would be what? Wait for 10 different Collections clones and
> choose the "best" for each project?
>
> I for one am tired of that.

There is, as a matter of fact, a difference of opinion on how specific
APIs should look and feel, across languages and within a language, as
well as across domains, and yes, I do believe experimentation does
help determine the "best possible" form that an API should take. The
declaration-site approach advocates opening certain interfaces up for
surgery, and sewing them up till the next Java release. In particular,
it means that there are only a few months to nail that down, which in
particular means we won't have much time to experiment with the API
before blessing it. And then the API will be a) forever a part of the
JDK and b) as a public API, unmodifiable until Java 8. I find that
limiting, and thus not likely to lead to the best set of extension
methods we could possibly hope for.

Regards
Patrick