[type-annos-observers] Clarifying the receiver parameter (qualified 'this')

[Alex Buckley]

It appears that the will of the EG regarding an inner class's 
constructor is that the name of the receiver parameter must be qualified 
by only a single Identifier. Allowing any name which could notionally 
serve as a qualified this expression in the ctor body has not found 
favor. Accordingly, I will change the JLS/JVMS draft to use "[Identifier 
.] this" as found in the java-annotation-design document.

Markus pointed out other infelicities concerning inner class 
constructors in the JLS/JVMS draft, so I will clarify all of this in one 
pass.

Alex

On 10/24/2013 11:53 AM, Doug Lea wrote:
>
> I confess that,  as soon as I noticed that the disputed
> issues are only to annotate inner classes nested at least two deep,
> I stopped caring much about outcome -- it will impact very
> few programs. If I ever encountered it, I'd probably recheck
> the specs/JLS anyway, so I don't have any expectations about
> naturalness.
>
> Given all that, I support the position that there is no
> real need to change things. The name "Outer.this" is
> only needed to distinguish from "this", and no extra
> qualification is needed. So the only question is
> whether it would be OK to allow extra qualification anyway.
> Unless someone comes up with a compelling reason, I'm
> fine with not allowing it.
>
> -Doug
>
>
> On 10/23/2013 05:34 PM, Michael Ernst wrote:
>>
>> The second issue is whether the specification should add a separate
>> note that
>> states that when writing
>>
>>       {Identifier .} this
>>
>> all the Identifiers must be outer class names and are forbidden from
>> being
>> package names.  In other words, the question is whether to create a
>> new class of
>> compiler errors that the compiler was forced to emit.  This adds
>> complexity to
>> the Java specification and to compiler implementations and test suites.
>>
>> I do agree with you in terms of code style.  When writing the
>> receiver, I would
>> advise programmers not to write a fully-qualified type -- that is, not
>> to write
>> the package components.  (Regarding rationale, it's true that the
>> receiver looks
>> like other formal parameters in some ways, but it is different in
>> other ways --
>> including not allowing modifiers like "final" and not being a simple name
>> because it permits dots as in "Outer.this". So absolute syntactic
>> similarity
>> with formal parameters is not possible.)
>>
>> That said, it is not the compiler's job to enforce good code style.
>> The fact
>> that this is a style point is a good argument against adding this
>> complexity to
>> the specification.
>>
>> The presence or absence of package names will have at most a minor
>> impact on
>> programmers.  I don't see much harm in either choice, and style
>> guidelines and
>> tools can set their own standards.  Thus, it doesn't feel like it is
>> worth
>> adding complexity to the language definition and to compilers, just to
>> prevent
>> package names from being written by programmers.
>>
>>                      -Mike
>>
>