On 5/27/15, 4:16 PM, "Michael Schmalle" <teotigraphix...@gmail.com> wrote:
>Ok, This needs to be clear to me before I go off to OZ.
>
>In Flex JS you have;
>
>Object.defineProperties(Base.prototype, /** @lends {Base.prototype} */ {
>/** @expose */
>text: {
>get: /** @this {Base} */ function() {
> return "A" + org_apache_flex_utils_Language.superGetter(Base, this,
>'text');
>},
>set: /** @this {Base} */ function(value) {
> if (value != org_apache_flex_utils_Language.superGetter(Base, this,
>'text')) {
> org_apache_flex_utils_Language.superSetter(Base, this, 'text', "B" +
>value);
> }
>}}}
>);
>
>I must use this obviously since hardly any actionscript could be cross
>compiled if you can't call super accessors.
I’m still surprised that in 2015, TS hasn’t been forced to handle super.
Are people not using inheritance much in TS?
>
>Alex, when you have time, can you explain what this is doing so I can
>implement it.
I have not read the spec, but Object.defineProperties appears to associate
a data structure with a “class”. When asked to interpret/execute
Someinstance.someprop
the JS runtime appears to check this data structure first, and call the
get or set as needed. As I see it, there is no way to switch from
SomeSubClass.someProp
back to
SomeBaseClass.someProp
and retain the ‘this’ pointer and scope. If you had a variable called
super it would still point to the same instance so super.someProp would
just cause the runtime to find the subclass’s property map.
In looking around the internet, the solutions seemed to:
1) get the superclass
2) get the property map of defined properties
3) get the getter or setter from the data structure
4) call it with the right ‘this’ pointer.
So that’s what is in the current JSFlexJSEmitter, but it assumes
goog.inherit is going to leave references to the base class in a
particular way. TS probably leaves references to base classes some how so
some abstraction around step 1 is probably required, but steps 2 through 4
can be the same.
It is step 4 that re-introduces “re-writing” that you may be referring to
as hell. The super setter again becomes a function call, so the AST walk
needs to know that and walk the tree differently, saving a whole branch to
be evaluated as the parameter to the function call. IOW, a binary
operator becomes a function call. I’ll bet there are still bugs in the
current JSFlexJSEmitter.
And I think I still haven’t fixed the scenario where only a getter or
setter is overridden. The generated code must propagate a “pass through”
for the missing getter or setter to the subclass’s data structure
otherwise the runtime will not find the setter or getter and think the
property is now read-only or write-only.
>
>So correct me if I am wrong but, since there is really no solution without
>an external utility to call a super accessor, we can't really say that
>this
>transpiler is producing vanilla javascript. Chicken egg thing.
Technically, you could inline everything in the utility function and still
called it vanilla. But it would be high-fat vanilla. ;-)
A question for Josh is whether it would be ok to have a Google Closure
Library dependency. These libraries exist to encapsulate some of these
object oriented patterns like finding the base class and loading
dependency definitions in a particular order. It seems to be somewhat
pay-as-you-go. If no inheritance, then almost no “goog”.
-Alex
