Yes. You understood me correctly, and you’re right. Dumb idea… ;-)
On May 4, 2016, at 2:47 AM, Alex Harui <aha...@adobe.com> wrote:
>
>
> 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
>
>
>
