Clarifying the receiver parameter (qualified 'this')

[Michael Ernst]

Markus-

Thanks for your helpful and clear message; now I understand your point.

> I just find it awkward that the 308.pdf replaced
> java-annotation-design.html's
>     [Identifier .] this
> with
>     {Identifier .} this
> and allows (fully-)qualified 'this' expressions as the name of the
> receiver parameter even where that's not necessary.

I'd like to treat these as two separate issues.


First, the change from
      [Identifier .] this
to
      {Identifier .} this
was essential.  The reason is that inside a doubly-nested inner class, the 
receiver can have a name like Outer.Middle.this.


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