Virtual extension methods -- a strawman design

[Jesse Kuhnert]

On Fri, May 14, 2010 at 9:54 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
<snipped/>
>
> Here's my rationale: adding closures to the language without closure-izing the
> libraries will be unsatisfying for the users.  Without a means of interface
> evolution, we cannot closure-ize the libraries.  We explored static extension
> methods, but they are pretty unsatisfying; it is impossible for an
> implementation to provide a better implementation.  If its true that "today's
> problems come from yesterday's solutions", static extension methods feel to me
> like tomorrow's yesterday's problematic solution (parse that if you can!)
>
>
>

Could you not add closures first and save the library changes for a
future update? The problem of retro-fitting the core API's does make
sense in terms of time frame but it's kind of now or never (or a few
years from now) in terms of having another opportunity to add them
without another new major version number isn't it?

It would be more ideal to have the libs retro-fitted but having the
language feature would be even more important in my opinion..Users can
find "satisifcation" in a future release while library designers /
toolers / etc can quietly add support for it in anticipation of a
future release update that expands and does the retro-fitting work..
maybe.