Extension vs defender methods

[Zhong Yu]

On Thu, Nov 10, 2011 at 12:44 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
> As Neal said, English is malleable.  If he wants to define "extension method" method to mean extended by a non-author, that's within the bounds of credibility.  We prefer to think of it as "extended after the fact".

But this feature is also very useful "before the fact"; an interface
author can use this feature in version0 of his API.

> (Another way to think of it is that the "extension" refers to the notion of interface; an interface with behavior is an "extended interface".)

Is there any interesting difference between interfaces with extension
method and interfaces without? As a programmer I don't see why I care
to give a special name to the former type. This feature is more on the
method level than on the interface level.

If we call it "extension method" we better have a credible explanation
of what it is "extending" from. To the lambda team "extension" makes
very good sense; but to programmers who see it as a general language
feature, "extension" is very perplexing. Can't we have a better name
to describe these "interface methods with default implementation"?

Zhong Yu

>
> To answer Paul's question, it is the interface that is being extended, beyond its original specification.  (Though the pedantically inclined might point out that one can add a default clause to an existing "original" method, turning it into a so-called "extension method", in a mostly binary and source compatible way.)
>
> The "weaver" is just an implementation trick, one that injects bytecodes into classes that inherit behavior from extended interfaces.  We don't intend this to be the real implementation, but its a darn convenient way to experiment.
>
> On Nov 10, 2011, at 12:55 AM, Paul Benedict wrote:
>
>> I like this clarification but we better ask the experts who built the
>> weaver :-) Are the concrete classes that extend List being woven or is the
>> interface?
>>
>> Paul
>>
>> On Wed, Nov 9, 2011 at 3:59 PM, Patrick Wright <pdoubleya at gmail.com> wrote:
>>
>>> It seems clear to me - a class implementing an interface, say
>>> ArrayList, is automatically *extended* (via redirection to the default
>>> implementation) to support new method(s) on List which were not part
>>> of List's original API. Without a default method provided by the
>>> mechanism, the class would have to be modified manually. It seems like
>>> a useful distinction: the class's implementation is being *extended*
>>> to include implementations it does not provide itself.
>>>
>>> The type in question is ArrayList - that is the type that is being
>>> extended - so we are adding functionality to the class not provided by
>>> its author.
>>>
>>> My interpretation, anyway.
>>>
>>>
>>> Best,
>>> Patrick
>>>
>>>
>>>> The meaning of extension in the phrase extension methods is that they
>>> allow
>>>> functionality to be added (i.e. extend) to a type that was not provided
>>> by
>>>> the author of the type.  I don't know in what sense you're using the term
>>>
>>>
>>
>
>
>