Default method survey results

Ezequiel Mario ezequielballesi at gmail.com
Mon Aug 13 09:39:29 PDT 2012 

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