> I’m still surprised that in 2015, TS hasn’t been forced to handle super.
Are people not using inheritance much in TS?
They tell them to use standard getValue(), setValue() in the property if
they need inheritance overrides.
I'm kind of bummed about this whole thing, I stuck my foot in mouth here,
since I totally forgot about this stuff. Since I really wanted to do this
for Josh's POC, I am interested in what he "needs" to get his project
working, Josh?
Mike
On Wed, May 27, 2015 at 7:51 PM, Alex Harui <aha...@adobe.com> wrote:
>
>
> 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
>
>
