On 5/3/16, 2:14 PM, "Harbs" <harbs.li...@gmail.com> wrote:
>Maybe I’m missing something, but why can’t we just use
>Object.defineProperty for overridden getters and setters?
>
>I do understand that the problem is when only one is overridden. We then
>need to define the other, but assuming we have access to the ActionScript
>of the super classes, the compiler can walk up the chain to get the
>original code. No?
Sounds like you are saying that if the base class getter/setters look like:
Object.defineProperty(BaseClass.prototype,
{
foo: {
get: function() { return this._foo; };
set: function(value) { this._foo = value; }
}
}
And the subclass does not specify an override of "get foo" that the
compiler should copy the getter from the base class into the subclass and
effectively duplicate:
Object.defineProperty(SubClass.prototype,
{
foo: {
get: function() { return this._foo; };
set: function(value) { this._foo = value; }
}
}
Technically that is probably possible, but it doesn't feel right because:
1) If the base class getter is 1000's of lines long, we'll end up copying
a lot of code.
2) The _foo should be private to the base class and not exposed to the
subclass. In fact, that might confuse the optimizer, or break code that
assumes privacy even though it can't be enforced at runtime.
3) The compiler does not know about the JS code for the base class, it
only knows the API signatures. Loading all of that JS code in order to
find and copy it would require a JS parser and potentially a lot of memory
and cpu cycles. We do currently get the JS code at publish time, but not
during code generation, and we only do a simple zip extraction of the JS
code.
HTH,
-Alex
