Default method survey results

Alex Blewitt alex.blewitt at gmail.com
Mon Aug 13 10:40:07 PDT 2012 

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