Different handing of "this" vs. "MyClass.this" in definite assignment

[Brian Goetz]

> I think Archie got at the heart of the problem in this comment here:
>
>> Presumably the reason for the different treatment is because in general the qualifying expression could be arbitrarily complex and the compiler can't be expected to detect any possible qualification in front of "foo", so why even start down that road?
> Exactly.  Don’t start down that road, unless (1) you know where it goes, and (2) that it gets somewhere good, and (3) you can get there before you run out of gas.  Don’t start just because you like the first billboard you see, or on a road which takes you to a tarpit, or with only enough supplies to travel on the first day of a week-long trip.  I think we might have all three problems here.

I think there are two different perspectives on `MyClass.this.x` that 
lead to two different views of the world.

For right or wrong, my mental model has always been that a field name 
`f` is shorthand for `this.f` which in turn is shorthand for 
`MyClass.this.f`.  Under this view, it makes sense to treat all the 
*names* of f equally, and all three of these are names for f.

The alternate view is that `MyClass.this.f` is, in fact, a reference to 
the *field* `MyClass.this` of an inner class (or some other expression 
that happens to contain `this`), and therefore is an arbitrary 
expression that we shouldn't try to analyze through, any more than 
`(this + 1 - 1).f` would be if we could do arithmetic on references.

Under the view to which I baselessly subscribe, treating 
`MyClass.this.f` as being the fully qualified name of `f` is more 
consistent, because it is just as much a "name for f" as the bare field 
or `this.f` is.

But I agree overall that this isn't worth spending a lot of 
spec-revision currency on.