Default method survey results
yshavit at akiban.com
Thu Aug 16 10:20:50 PDT 2012
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.
> On Thu, Aug 16, 2012 at 11:35 AM, Peter Levart <peter.levart at marand.si>
> > Just one more, then I quit (for a while).
> > The phylosophical question is whether the "default" modifier actualy
> > 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 -
> > 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
> > interfaces, then it does not represent a default method.
> > Such interface-only hierarchy could be observed in a system that
> > generates anonymous classes that implement such interfaces and never
> > "override" concrete methods on interfaces (say java.lang.reflect.Proxy).
> > 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
> >> > depending on where they are defined in (interface or class).
> >> >
> >> > So do we need two types of methods with a body: concrete / default -
> >> > 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
> >> 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
> >> also become an optional modifier on concrete class methods. For
> >> consistency's sake.
> >> Should this modifier be called "default" ? I don't know.
> >> Peter
More information about the lambda-dev