Default method survey results

Ezequiel Mario ezequielballesi at gmail.com
Mon Aug 13 11:01:32 PDT 2012 

Yes you are right,
As you say, all method on interfaces are abstract and they require not to
say so explicitly, as in

public interface Foo {

public void foo();

But if they want to provide a default implementation they should say so
explicitly, as in:

public interface Foo {

public default void foo() {

…

}


By similarity, all method of a class are concrete (need implementation) and
they don't require to say so explicitly, as in:

public class Foo {

                public void foo() {

                …

}

But if they want to be abstract (don't provide an implementation), they
need to say so explicitly (and also mark the class as abstract), as in:

public abstract class Foo {

                public abstract void foo() ;



That seems to me homogeneous, “in a somehow negated/symmetric way” (not a
native speaker), don’t you think so?


On Mon, Aug 13, 2012 at 2:40 PM, Alex Blewitt <alex.blewitt at gmail.com>wrote:

> By that argument, the keyword 'abstract' should be required for all
> interfaces. Yet it is not, on the observation that all interfaces are
> abstract. By similarity, every non-abstract method in an interface will be
> 'default' and yet that keyword will not be optional.
>
> Alex
>
> On 13 Aug 2012, at 17:39, Ezequiel Mario wrote:
>
> > Just trying to give a constructive view:
> >
> >
> > I think the keyword is a good approach, as Maurizio said it says loud and
> > clear what it is, as when you read “public abstract class …” or “public
> > abstract void foo()”. Even though the compiler can handle the syntax
> > without the keyword, one could argue the same for the abstract keyword,
> > right?. The main line seems to be not whether the compiler can easily
> > handle the syntax, but whether the human reading it can do it as easily
> as
> > without it?
> >
> >
> > Also I think that, since right now you express your intent of not
> providing
> > an implementation in a class for a method as “public abstract void
> foo();”,
> > it seems perfectly reasonable to express in an interface your intention
> of
> > providing one that is default “somewhat” in a similar syntax “public
> > default foo() {}”; maintaining “in my view” homogeneity between both
> > declarations.
> >
> >
> > Keep up the good work!
> >
> >
> > On Mon, Aug 13, 2012 at 11:47 AM, Yuval Shavit <yshavit at akiban.com>
> wrote:
> >
> >> There have been discussions within the last few days, on this mailing
> list,
> >> about how people wish that Java had a keyword for package-private
> >> visibility. Insofar as we should learn from the past, this seems to me a
> >> nudge towards the direction of having one for defenders. That said, my
> >> argument for where to place the "default" keyword (assuming there is
> one)
> >> can also back the no-keyword camp.
> >>
> >> I agree with the survey's description of what "default" would mean in
> each
> >> place. But I voted in the minority, exactly because to me, the concept
> of a
> >> "default method" is not very useful.
> >>
> >> As a user of an interface with such a method, I don't care if it has a
> >> default implementation -- I just care that it has some implementation.
> As
> >> an implementer of such an interface, I don't care what "kind" of method
> it
> >> is as much as whether I need to implement it; many times I'll be
> >> implementing it via an abstract class like AbstractList, anyway, so
> default
> >> methods are not the only ones for which I don't need to provide an
> >> implementation. Or do I need to switch my mindset, such that if
> >> AbstractList provides an implementation of iterator(), that is now a
> >> "pseudo-default" method from my perspective? And as the interface
> writer, I
> >> don't even really care about the fact that it has a default
> implementation
> >> (unless final defaults come in later). I only care that the method
> exists
> >> at all.
> >>
> >> In other words, what does the concept of a "default method" add to how
> >> anybody thinks about the interface?
> >>
> >> With abstract methods, I always viewed the "abstract" keyword as a
> >> confirmation to the compiler: "my semicolon isn't a typo -- this is
> really
> >> a pure virtual function." I would view the "default" keyword the same
> way,
> >> and in that context it seems to fit well between the signature and the
> >> body.
> >>
> >> On Mon, Aug 13, 2012 at 10:25 AM, Collin Fagan <collin.fagan at gmail.com
> >>> wrote:
> >>
> >>> As much as developers would like them to be, and as much as modern
> >>> frameworks treat them as such, annotations are not keywords.
>  Annotations
> >>> were intended only to add information and not to actually change the
> >>> meaning of anything in the language. Frameworks can blur the lines if
> >> they
> >>> wish but I think the Java language itself should not break it's own
> rules
> >>> for this one case.
> >>>
> >>> Collin
> >>>
> >>> On Mon, Aug 13, 2012 at 9:09 AM, Jose A. Illescas <
> >>> jantonio.illescas at rbc.com
> >>>> wrote:
> >>>
> >>>> Gregg,
> >>>>
> >>>>   Compiler can add "default" keyword for every method (on interface)
> >>>> with implementation (delimiteded with "{...}" instead of "default")
> >>>>
> >>>>   Demarcations on developer hands are ugly, (I think) must be resolved
> >>>> by compiler...
> >>>>
> >>>>
> >>>> On 13/08/2012 15:52, Gregg Wonderly wrote:
> >>>>> In this day and age of the Java language, reusing existing keywords,
> >>>>> trying to shoehorn them into use for a new purpose, can feel a little
> >>>>> clumsy.  Annotations can provide a much better mechanism in many
> >>>>> cases, simply because the right nomenclature is helpful.
> >>>>>
> >>>>> However, annotations also have a very specific usage scenario with
> >>>>> tooling and moment-of-use issues.  For me, this means that you can't
> >>>>> use annotations in places that annotations wouldn't work with the
> >>>>> normal annotation tooling.  You certainly don't want to have to have
> >> a
> >>>>> special class of annotation that further confuses the use of
> >>>>> annotations in other cases.
> >>>>>
> >>>>> The use of "default" isn't awesome, but it does provide a usable
> >>>>> demarcation which the compiler and run-time class loading can use to
> >>>>> make the right decision for how to build the v-tables to dispatch the
> >>>>> default method should it be involved some how.
> >>>>>
> >>>>> Gregg Wonderly
> >>>>>
> >>>>> On 8/13/2012 8:35 AM, Jose A. Illescas wrote:
> >>>>>> On 13/08/2012 15:23, Deepak S Patwardhan wrote:
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: lambda-dev-bounces at openjdk.java.net [mailto:lambda-dev-
> >>>>>>>> bounces at openjdk.java.net] On Behalf Of Jose A. Illescas
> >>>>>>>> Sent: 13 August 2012 16:40
> >>>>>>>> To: Brian Goetz
> >>>>>>>> Cc: lambda-dev at openjdk.java.net
> >>>>>>>> Subject: Re: Default method survey results
> >>>>>>>>
> >>>>>>>> Brian, Why not add one thirth option (without "default" keyword)
> >> to
> >>>>>>>> poll?
> >>>>>>>>
> >>>>>>>> 1.  void foo() default {
> >>>>>>>>            System.out.println("foo");
> >>>>>>>>        }
> >>>>>>>>
> >>>>>>>> 2.  default void foo() {
> >>>>>>>>            System.out.println("foo");
> >>>>>>>>        }
> >>>>>>>>
> >>>>>>>> 3.     void foo() {
> >>>>>>>>
> >>>>>>>>            System.out.println("foo");
> >>>>>>>>        }
> >>>>>>>>
> >>>>>>> If we explore going down this path, I think we should also explore
> >>>>>>> using an
> >>>>>>> annotation,
> >>>>>>>
> >>>>>>> @java.lang.Default
> >>>>>>> void foo() {
> >>>>>>>      System.out.println("foo");
> >>>>>>> }
> >>>>>>>
> >>>>>> Deepak, why proposed annotation?
> >>>>>>
> >>>>>>      I would like see an implementation as any other java method
> >>>>>> (without new keywords, annotations, ...)
> >>>>>>
> >>>>>>      Implements a interface method ("default") must be equals to
> >>>>>> implement another class method (I want "complexity" out of developer
> >>>>>> hands, into compiler...)
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> I would be interested in knowing if using such an annotation has
> >> any
> >>>>>>> demerits.
> >>>>>>>
> >>>>>>> Regards,
> >>>>>>> Deepak S Patwardhan.
> >>>>>>>
> >>>>>>>>
> >>>>>>>> On 12/08/2012 00:30, Brian Goetz wrote:
> >>>>>>>>> Poll is closed, and results can be seen here:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>> https://www.surveymonkey.com/sr.aspx?sm=xPw4AxfWK2TTQLQtbIpQCg0l
> >>>>>>>> bkw_2fuYDiZnrBDB_2bPyd4_3d
> >>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>
> >>
> >
>
>

More information about the lambda-dev mailing list