[type-annos-observers] Clarifying the receiver parameter

Alex Buckley alex.buckley at oracle.com
Wed Apr 17 10:25:08 PDT 2013


I presume you're asking about the qualified name of the receiver 
parameter of a method (not a ctor) _of a top-level class_?

The answer is consistency. Since the receiver parameter intends to 
denote the receiver of the method, the receiver parameter's name should 
be textually equivalent to any 'this' expression which would denote the 
receiver of the method in the method body. An unqualified 'this' in the 
method body is the common case, but qualified 'this' expressions are 
also legal there. Would you ban a qualified 'this' expression like 
"p.C.this" because it's "always redundant"? Too late; the language 
already took the path of allowing both simple and qualified names to 
refer to the same entity.

Alex

On 4/16/2013 10:33 PM, Srikanth S Adayapalam wrote:
> Alex, Could you please provide some rationale/justification for why a
> fully-qualified name as qualifier of a the receiver parameter's "this" is
> necessary ?
>
> The qualifier would always be redundant and is therefore best not allowed
> obviating the need for a different grammar. The only situation where the
> "this" parameter needs a qualifier
> is in the constructor of an inner class.
>
> It is agreed that jsr308 spec in 2.1.5 is not entirely clear about the
> correct usage of the receiver parameter's "this". It should specify the
> allowed constructs, rather than just give an example.
>
> Srikanth
>
> type-annotations-spec-experts-bounces at openjdk.java.net wrote on 04/11/2013
> 06:24:09 AM:
>
>> From: Alex Buckley <alex.buckley at oracle.com>
>> To: type-annotations-spec-experts <type-annotations-spec-
>> experts at openjdk.java.net>,
>> Date: 04/11/2013 06:24 AM
>> Subject: Clarifying the receiver parameter
>> Sent by: type-annotations-spec-experts-bounces at openjdk.java.net
>>
>> There is some confusion around i) the type and ii) the name of the
>> formal parameter which represents the receiver of an inner class's
>> constructor or instance method.
>>
>> The current text is just "For a method, the receivers are named this,
>> Outer.this, etc." and "Within an inner class constructor, the receiver
>> has a name such as Outer.this". This doesn't help with the legality of
>> the following receiver parameters, both of which should be legal:
>>
>>     package p;
>>     class Outer {
>>       class Inner {
>>         Inner(p.Outer p.Outer.this) {}
>>       }
>>     }
>>
>>     package p;
>>     class Outer {
>>       class Middle {
>>         class Inner {
>>           Inner(Outer.Middle Outer.Middle.this) {}
>>         }
>>       }
>>     }
>>
>> It needs to be stated that: "The receiver of a constructor or instance
>> method of an inner class C, a direct inner class of O (8.1.3), is
>> denoted by a formal parameter which appears first in the formal
>> parameter list, and whose type is O, and whose name is a qualified this
>> expression (15.8.4) which would, if used in the body of the constructor
>> or instance method, refer to the immediately enclosing instance of the
>> instance of C."
>>
>> By saying "whose type is O", we delegate to the normal process of
>> resolving a type name. And by saying the name is that of a qualified
>> this expression, we get the type resolution of the ClassName in a
>> qualified this.
>>
>> Finally, we should apply the same technique for non-inner ctors/methods:
>>
>> "The receiver of a constructor or instance method of a top-level class C
>> is denoted by a formal parameter which appears first in the formal
>> parameter list, and whose type is C, and whose name is a this expression
>> (15.8.3) or qualified this expression (15.8.4) which would, if used in
>> the body of the constructor or instance method, refer to the instance of
> C."
>>
>> which rightly allows:
>>
>> package p;
>> class C {
>>     void m(p.C p.C.this) {}
>> }
>>
>> (We need to allow a qualified this expression as the name because such
>> an expression in the body can refer to _any_ lexically enclosing
>> instance of C _including the zeroth lexically enclosing instance of C_
>> which is C itself.)
>>
>> Alex
>>
>


More information about the type-annotations-spec-observers mailing list