Default method survey results

[Peter Levart]

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