new keyword 'extension' really necessary?

[Osvaldo Doederlein]

2010/8/5 Rémi Forax <forax at univ-mlv.fr>:
> Le 05/08/2010 20:25, Osvaldo Doederlein a écrit :
>> Extension methods are not allowed inside annotations, so I guess the
>> implementation and spec issues are at least less severe, as
>> disambiguation is trivial by the outer context being an annotation or
>> not. Maybe it can't be completely handled by (simple) grammar changes,
>> but that would be about it (it seems; correct me if that's wrong).
>
> In fact, there is no 'grammar' problem.
> The local keyword 'extension' avoid to change too much the javac parser,
> a hand written top-down recursive parser.
>
> But the real value is, as Brian says, that an extension method
> is tagged with the local keyword 'extension'.
> Easy to explain, easy to grasp.

You imply that without 'extension', the syntax is hard to explain,
hard to grasp. This is where I disagree. This verbose, DRY-violation
syntax won't buy anything; 'default' is perfectly fine, I don't think
programmers will be confused. Notice also that you assume that
programmers want to make the association between the syntax and the
feature name "extension method", but this name is just a convention
and in some degree arbitrary - we could decide to use "defender
method", or maybe even "default method" [in that case the 'default' is
certainly sufficient ;-) ]

Don't underestimate the ability of programmers to coalesce different,
but correlated features, into a common abstract model (my comment
below) with shared syntax. All programming languages do this all the
time, in many different situations. For example, C++ famously uses "=
0" for abstract method declarations; when I was a C coder who started
learning C++ I considered this pretty cool and natural, because
zero/NULL is a very big concept in C/C++ (much more so than in Java
with its well-behaved and restricted pointers, lack of function
pointers etc.)... declaring "virtual void f() = 0" is intuitive, it
recalls an explicit function pointer table that contains zero or NULL
for that function, only concrete subclasses will have a similar table
with a non-null pointer in the same slot. The learning C -> C++
convert will understand this even if not familiar with the structure
of vtables, which are much more complex than the explicit function
pointer tables that C programs would use for similar needs.

>> And I think the similar style (same syntax for annotation defaults and
>> for extension methods) is actually good. These are basically the same
>> thing, in a very abstract level: a structure (interface or annotation)
>> that has some feature (annotation field or method) which offers a
>> default "value".
>>
>>
>
> Rémi
>
>> 2010/8/5 Brian Goetz<brian.goetz at oracle.com>:
>>
>>> In addition to Maurizio's syntactic arguments, we believe there is value in
>>> identifying extension methods as, well, extension methods.
>>>
>> By the same logic, maybe we need an army of new redundant qualifiers
>> such as "method", "field", etc.?
>>
>> (OTOH, we already have some redundant qualifiers - like 'abstract' for
>> a method signature that's not followed by '{', or allowing 'private
>> final' methods and 'public' interface methods, or 'final' for
>> arguments in abstract method declarations. But I don't want more of
>> the same.)
>>
>> A+
>> Osvaldo
>>
>>
>>> On 8/5/2010 12:33 PM, Gernot Neppert wrote:
>>>
>>>> Hi Maurizio,
>>>>
>>>> I do not have compiler writing skils, so I'm curious why the keyword
>>>> 'extension' should be nessesary to introduce defender methods.
>>>> A defender method declaration without the prefix 'extension' looks quite
>>>> distinguishable to me. Example:
>>>>
>>>> interface List<E>
>>>> {
>>>>       void sort(Comparator<? super E>    comp) default Collections.sort(List<E>);
>>>> }
>>>>
>>>> So, why the new keyword?
>>>>
>>>> (An answer such as 'This is necessary to disambiguate the grammar' would
>>>> suffice...)
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>
>
>