"final" ReceiverParameter?
Alex Buckley
alex.buckley at oracle.com
Tue Oct 22 14:13:44 PDT 2013
I also agree with syntactically disallowing 'final' on a receiver
parameter, for three reasons:
1. Historically, 'final' was disallowed in the
java-annotation-design.pdf document: the FormalParameterOrReceiverDecls
production did not allow VariableModifier terms before the receiver
parameter (section 2.2 item 5). A recent javac allows 'final' in this
location, which is a bug.
2. Conceptually, the receiver parameter has no effect on the rest of the
code - it is specified as "an optional syntactic device" - so it would
be confusing for an effect-free 'final' to appear.
3. Semantically, 'final' is a modifier for a _variable_, while 'this' is
not a variable (it is a keyword that denotes a value) and the receiver
parameter is not a variable declaration. So, the idea of a "final
'this'" is unsound.
I will modify the ReceiverParameter production in the JLS draft to use
{Annotation} rather than {VariableModifier}.
Alex
On 10/22/2013 9:05 AM, Michael Ernst wrote:
> I concur with both of these comments. Thanks, Markus, for your careful reading!
>
> -Mike
>
>
>> Subject: "final" ReceiverParameter? (was: Public Review for JSR 308)
>> From: Markus Keller <markus_keller at ch.ibm.com>
>> To: type-annotations-spec-comments at openjdk.java.net
>> Date: Mon, 21 Oct 2013 17:32:16 +0200
>>
>> Alex Buckley <alex.buckley at oracle.com> wrote on 2013-10-16 20:32:38:
>>
>>> http://cr.openjdk.java.net/~abuckley/308.pdf
>>
>> Two more nits:
>>
>> 1.
>>
>> ReceiverParameter:
>> {VariableModifier} UnannType {Identifier .} this
>>
>> VariableModifier syntactically allows annotations and "final". I don't
>> think "final" makes sense here, not even optional. {VariableModifier}
>> would better be replaced by {Annotation}. Otherwise, we'd need some spec
>> text that tells that "final" is not a legal modifier for a receiver
>> parameter.
>>
>> 2. Typo on p.18: "that type is the type is the newly constructed object"
>> => 2nd "is" should be "of" ^^
>>
>> Markus
More information about the type-annotations-spec-experts
mailing list