Virtual extension methods -- a strawman design

Jesse Kuhnert jkuhnert at
Sat May 15 09:06:50 PDT 2010

On Fri, May 14, 2010 at 9:54 PM, Brian Goetz <brian.goetz at> wrote:
> 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..

More information about the lambda-dev mailing list