Default method survey results
peter.levart at marand.si
Thu Aug 16 09:35:14 PDT 2012
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?
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.
More information about the lambda-dev