Extension vs defender methods

[Paul Benedict]

+1 for "default method" and we shouldn't say the interface has a default
method, but the implementing class will have a default implementation.

On Sat, Nov 12, 2011 at 3:16 PM, Sam Pullara <sam at sampullara.com> wrote:

> Would "default method" not be accurate and obvious?
>
> Sam
>
> On Nov 12, 2011, at 10:45 AM, Zhong Yu wrote:
>
> > 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
> >>>>
> >>>>
> >>>
> >>
> >>
> >>
> >
>
>
>