> De: "Brian Goetz" <brian.go...@oracle.com>
> À: "Remi Forax" <fo...@univ-mlv.fr>
> Cc: "amber-spec-experts" <amber-spec-experts@openjdk.java.net>
> Envoyé: Lundi 18 Mars 2019 16:19:19
> Objet: Re: Concise method bodies with delegation and this

>> There are two syntaxes, the arrow syntax and the colon-colon syntax, i think
>> there is consensus that the arrow syntax (the one Brian uses) is nice and
>> convenient.

> I don’t really even think there’s consensus there; it is nice and convenient 
> and
> mostly unobjectionable, but some felt “meh, what’s the point”, as it merely
> eliminates a few characters of typing.

Especially if you still have a big javadoc comment as Kevin said. 
I think this feature shine when you override a method, because the semantics is 
already defined (usually you don't need any javadoc), the poster child being 
implementing Comparable as Victor said. 

And BTW, i still think we should come with a shorter syntax for overridden 
method by allowing to not declare parameter types like with a lambda, 
class Person implement Comparable<Person> { 
private final int id; 
// more fields 

override equals(o) -> (o instanceof Person p)? p.id == id : false; 
override hashCode() -> id; 
override compareTo(p) -> Integer.compare(id, p.id); 
} 

> The implementation-by-delegation sub feature is far more substantial; it 
> allows
> you to implement a class by wiring its declarations to existing reusable
> behaviors. This has far more potential benefit, but also more cost.

yes, but i believe part of the cost is because the current proposed syntax is 
reusing the syntaxic operators = and :: but with a slightly different 
semantics. 

>> - using '=' to set a concise method make the syntax easy to confound with a
>> field initialization (something which is ok in Scala because the Scala syntax
>> also blur that distinction between a method call and a field access, it's 
>> less
>> ok in Java IMO).

> Please, can we not harp on notation unnecessarily?

i disagree here because i think that the proposed syntax is part of the issue 

>> I really dislike the notation

> Please, can we not harp on notation unnecessarily?

fair point for this one. 

Rémi 

Reply via email to