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

[Doug Lea]

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
>