Default method survey results

[Yuval Shavit]

So... get rid of static typing? I would strongly vote against this.

On Thu, Aug 16, 2012 at 1:10 PM, Paul Benedict <pbenedict at apache.org> wrote:

> The oddity of "default" implementation is that it puts the programmer
> in a box. He has to provide some sort of implementation that does not
> rely on state. That's an odd place to be in -- especially if no
> suitable implementation can be given without state.
>
> Why not get rid of default implementations all together? Allow
> interfaces to be extended at will and the JVM simply throws a
> NotImplementedException (ala C# or Apache Commons Lang) if there is no
> overriding implementation.
>
> Paul
>
> On Thu, Aug 16, 2012 at 11:35 AM, Peter Levart <peter.levart at marand.si>
> wrote:
> > Just one more, then I quit (for a while).
> >
> > The phylosophical question is whether the "default" modifier actualy
> specifies
> > the type of a method in itself. I think it does not. The method is either
> > "concrete" (with a body) or "abstract" (just signature).
> >
> > The "concrete" interface method becomes default in a specific context -
> when
> > used in hierarchy with a class. Only in hierarchy with a class it
> specifies a
> > default implementation which is used if not overriden with a class
> method of
> > any type (abstract or concrete).
> >
> > If "concrete" interface method is observed in the context where there's
> only
> > interfaces, then it does not represent a default method.
> >
> > Such interface-only hierarchy could be observed in a system that
> automatically
> > generates anonymous classes that implement such interfaces and never
> > "override" concrete methods on interfaces (say java.lang.reflect.Proxy).
> Can
> > those concrete interface methods be called "default" methods then?
> >
> > Regards, Peter
> >
> > On Thursday, August 16, 2012 06:08:01 PM Peter Levart wrote:
> >> On Thursday, August 16, 2012 05:27:08 PM Peter Levart wrote:
> >> > So we already have one type of methods (abstract) that play
> differently
> >> > depending on where they are defined in (interface or class).
> >> >
> >> > So do we need two types of methods with a body: concrete / default -
> each
> >> > one  designated for a specific container interface / class, just to
> >> > indicate how they play in the hierarchy?
> >>
> >> I don't think we need a 3rd type of virtual methods (default). I think
> it's
> >> easier to reason when default == concrete.
> >>
> >> But do we need a mandatory modifier on the methods with-a-body of the
> >> interface? Yes, for consistency's sake. But then this same modifier
> should
> >> also become an optional modifier on concrete class methods. For
> >> consistency's sake.
> >>
> >> Should this modifier be called "default" ? I don't know.
> >>
> >> Peter
> >
>
>