Packages name conflicting with getters and setters?

Question

Hello, folks. So, I've came across this compilation error a while ago.. As there's an easy fix and I didn't find anything relevant at the time, I eventually let it go.

I just remembered it and I'm now wondering if this is really part of the language grammar (which I highly doubt) or if it's a compiler bug. I'm being purely curious about this -- it doesn't really affect development, but it would be nice to see if any of you have seen this already.

package view {
    import flash.display.Sprite;

    public class Main extends Sprite {
        private var _view:Sprite = new Sprite();

        public function Main() {
            this.test();
        }

        private function test():void {
            trace(this.view.x, this.view.y);
            //1178: Attempted access of inaccessible property x through a reference with static type view:Main.
            //1178: Attempted access of inaccessible property y through a reference with static type view:Main.
            //Note that I got this due to the package name.
            //It runs just fine if I rename the package or getter.
        }

        public function get view():Sprite {
            return this._view;
        }
    }
}

Answer 1

I'd say this is either a compiler bug or an inconsistency in the spec.

Quote from the chapter 11.1 Package namespace (I'd link directly, but the docs use frames):

Packages exist only at compile time. The static existence of packages allows us to give them certain properties that would not be possible if they could be manipulated at runtime. In particular:

Package names may have embedded dots. Fully qualified package references may and must be expressed using the dot operator rather than the usual :: syntax for qualified names.

But because there is no runtime value for a package name, packages cannot be aliased or otherwise used in an expression that uses a runtime value.

When encountered in a valid context by the compiler, the meaning of a package name becomes fixed; any interpretation at runtime is no longer possible.

For this reason, a package name always shadows locally defined names, independent of the scope chain, when that package name is used on the left hand side of a dot operator.

Now, from the above, I gather that this line:

trace(this.view.x, this.view.y);

Shouldn't be interpreted by the compiler as refering to the view package, since it seems to contradict this point -- I'll call it A):

packages cannot be aliased or otherwise used in an expression that uses a runtime value

Because this, unless I'm mistaken, is a runtime value.

Then, if you use this the ambiguity could be solved as your getter, I think, but according to this paragraph -- let's call it B), it won't:

For this reason, a package name always shadows locally defined names, independent of the scope chain, when that package name is used on the left hand side of a dot operator.

So, if you don't use this, it's clear from the spec that view.x should be interpreted as a reference to the defintion of x in the view package.

If you explicitly say this, there's a contradiction between A) and B), as I see it. According to A) there should be no aliasing; but the aliasing is happening, it seems, because there's a package name used on the left of a dot operator. So my guess is the compiler is not parsing the package in context, so to speak, just checking if any name on the left of a dot operator matches the name of a defined package.