Default method survey results

[Paul Benedict]

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
>