Concise method body + type inference ?
Alex Buckley
alex.buckley at oracle.com
Thu Oct 4 00:30:12 UTC 2018
On 10/3/2018 4:06 PM, John Rose wrote:
> On Oct 3, 2018, at 3:56 PM, Alex Buckley <alex.buckley at oracle.com
> <mailto:alex.buckley at oracle.com>> wrote:
>>
>> Let's say that Java 5 had the right idea by coupling an overriding
>> method to an overridden method, via @Override. Then, your proposal is
>> at odds with Java 5, because omitting the method signature of the
>> overriding method also means omitting @Override. (I assume you
>> intended for there to be no annotations on your lambda-like method
>> bodies such as `hashNext() -> index < end;`)
>
> Put another way, Remi's suggestion is for a coupling stronger
> than @Override, which is purely advisory. An 'override'
> modifier would upgrade the advice to something mandatory,
> at which point types might from from the super.
If you write @Override, then it's not just advice to the compiler that
you intend to override something; it's a statement that you DO override
something. You get a compile-time error if you don't. It's an `override`
modifier in all but spelling.
But yes, Remi is saying that some method declarations have become so
full of redundant information -- the signature types, the accessibility
modifier, the @Override annotation, the {} and `return` for the body --
that it's time to reject the redundancy and go for concision not only in
the body but in the declaration as a whole.
Brian has already made the argument to infer only within the method's
implementation -- meaning within the method's body, not for the method
declaration as a whole. I think Remi views the whole method declaration
as "implementation", of the overridden method, and concludes that
inferring the signature et al is reasonable. But it's rather arbitrary
to give an overriding method the sole right to a concise declaration,
and not a `private` method, a `final` method, a `default` method, etc.
Alex
More information about the amber-spec-experts
mailing list