[jsr-335-eg] Default method survey results

Remi Forax forax at univ-mlv.fr
Sun Oct 21 11:43:39 PDT 2012

On 10/21/2012 04:03 PM, Brian Goetz wrote:
>>> And one obvious one we forgot (which was the one we started with!):
>>>   extension void foo() { … }
>> It think this one is very misleading. Those who knew the term before, 
>> would think this is not what it actually is.
>> Those who didn't know the term before will be OK until they come 
>> across the same word in the different context.
>> Let's avoid this confusion.
> I get your point, but just because C# happened to come up with 
> something they decided to call extension methods a few years ago, 
> doesn't mean that extension methods must be inherently use-site or 
> static or otherwise like C#'s interpretation.  The core concept of 
> after-the-fact extension is what counts; the mechanism 
> (monkey-patching vs accretion) and the specific characteristics 
> (static vs virtual) differ, but these are details -- if C# had virtual 
> extension methods, they still would probably call them extension methods.

Eclipse codebase coins the term extension interface for implementing 
virtual extension methods (or delegate methods BTW) before C# introduced 
its extension methods mechanism.

Also Java enum are not C enum but provide the very same concept even if 
the implementation is different.

>> It is almost as bad as saying that Java 8 has traits.
> Fortress had stateless traits; these were just as much real traits as 
> Scala's stateful traits.  People who know one language don't notice; 
> people who know more are used to the same concept (e.g., class) 
> meaning slightly different things in different languages.

Right, Java 'traits' are more traits than Scala one because the common 
definition of traits say they are stateless.

> Other opinions?  For all its faults, is "default" better than 
> "extension"?

I prefer 'extension' because for once Java will not reuse a keyword for 
another meaning,
default is already used to specifying default value of an annotation 


More information about the lambda-spec-experts mailing list