I just tried in babel, see what it generates:
http://babeljs.io/repl/#?experimental=true&evaluate=true&loose=false&spec=false&code=class%20A%20{%0A%09constructor%28%29%20{%0A%09%20%20this._property%20%3D%20%22init%22%3B%0A%09}%0A%09get%20property%28%29%3Astring%20{%0A%09%09return%20this._property%3B%0A%09}%0A%09%0A%09set%20property%28value%3Astring%29%20{%0A%09%09this._property%20%3D%20value%3B%0A%09}%20%0A%09%0A%09showMyValue%28%29%20{%0A%09%09alert%28this._property%29%3B%0A%09}%0A%0A}%0A%0Aclass%20B%20extends%20A%20{%0A%09get%20property%28%29%3Astring%20{%0A%09%09return%20super.property%3B%0A%09}%0A%09%0A%09set%20property%28value%3Astring%29%20{%0A%09%09super.property%20%3D%20value%3B%0A%09}%0A}
Frédéric THOMAS
> Date: Thu, 28 May 2015 06:54:31 -0400
> Subject: Re: [FalconJX] JXEmitter accessors
> From: teotigraphix...@gmail.com
> To: dev@flex.apache.org
>
> > 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
> >
> >
