flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Frédéric THOMAS <webdoubl...@hotmail.com>
Subject RE: [FalconJX] JXEmitter accessors
Date Thu, 28 May 2015 12:41:41 GMT
> So what is different about this?
> 
> The only thing I can think of is that we introduce utility functions to do
> the work

Yes, that, I guess both of the language inherit in the same way, if yes, this function is
re-usable IMO

Frédéric THOMAS

> Date: Thu, 28 May 2015 08:38:16 -0400
> Subject: Re: [FalconJX] JXEmitter accessors
> From: teotigraphixllc@gmail.com
> To: dev@flex.apache.org
> 
> Well yes, I follow the logic. I don't understand if this is a solution, why
> TypeScript doesn't use the same algorithm.
> 
> I read what the developers said and they said they had talked about it in
> length when the project first started and came to the conclusion there
> really is no solution.
> 
> So what is different about this?
> 
> The only thing I can think of is that we introduce utility functions to do
> the work and they didn't want to do that, I did get this from the
> conversation, they stated they wanted it to be plain javascript, the only
> helper they use is _extends function they write out for inheritance.
> 
> I was thinking about TypeScript, other than the language difference, there
> is really NO difference in our compiler and what they do. Which is cool
> because all the usecases that they have will apply to this emitter.
> 
> Plus we have libraries and IDE support and possible MXML in the future.
> 
> Mike
> 
> On Thu, May 28, 2015 at 8:27 AM, Frédéric THOMAS <webdoublefx@hotmail.com>
> wrote:
> 
> > I'm not a javascript guru either, but it was easy to create ES6 classes
> > (left pane) and see the output (right pane), so, for the setter, it creates:
> >
> > For class A (simple):
> >
> >         get: function () {
> >             return this._property;
> >         },
> >         set: function (value) {
> >             this._property = value;
> >         }
> >
> > For class B:
> >
> >
> > set: function (value) {
> >             _set(Object.getPrototypeOf(B.prototype), "property", value,
> > this);
> >         }
> >
> > Which calls:
> >
> > var _set = function set(object, property, value, receiver) {
> >     var desc = Object.getOwnPropertyDescriptor(object, property); // Get
> > the property on B
> >     if (desc === undefined) { // If not overrided, will set the parent
> > recursively if the parent doesn't override the property either.
> >         var parent = Object.getPrototypeOf(object);
> >         if (parent !== null) {
> >             set(parent, property, value, receiver);
> >         }
> >     } else if ("value" in desc && desc.writable) { // didn't get this part
> >         desc.value = value;
> >     } else { // Else call the setterv of this Object
> >         var setter = desc.set;
> >         if (setter !== undefined) {
> >             setter.call(receiver, value);
> >         }
> >     }
> >     return value;
> > };
> >
> >
> > get: function () {
> >             return _get(Object.getPrototypeOf(B.prototype), "property",
> > this);
> >         },
> >
> > Which calls:
> >
> > this for the getter, do recursive call to the prototype to check if the
> > property has been overriden, if Yes, get the value.
> >
> > var _get = function get(_x, _x2, _x3) {
> >     var _again = true;
> >     _function: while (_again) {
> >         var object = _x, property = _x2, receiver = _x3;
> >         desc = parent = getter = undefined;
> >         _again = false;
> >         var desc = Object.getOwnPropertyDescriptor(object, property);
> >         if (desc === undefined) {
> >             var parent = Object.getPrototypeOf(object);
> >             if (parent === null) {
> >                 return undefined;
> >             } else {
> >                 _x = parent;
> >                 _x2 = property;
> >                 _x3 = receiver;
> >                 _again = true;
> >                 continue _function;
> >             }
> >         } else if ("value" in desc) {
> >             return desc.value;
> >         } else {
> >             var getter = desc.get;
> >             if (getter === undefined) {
> >                 return undefined;
> >             }
> >             return getter.call(receiver);
> >         }
> >     }
> > };
> >
> > Does it do the trick ?
> >
> > Frédéric THOMAS
> >
> > > Date: Thu, 28 May 2015 07:47:45 -0400
> > > Subject: Re: [FalconJX] JXEmitter accessors
> > > From: teotigraphixllc@gmail.com
> > > To: dev@flex.apache.org
> > >
> > > Interesting Fred, I am no javascript guru so I need people to "tell" me
> > > what I should have output.
> > >
> > > So let me get this straight, the left pane is ES6 and it converted it to
> > > ES5 in the right pane?
> > >
> > > Mike
> > >
> > > On Thu, May 28, 2015 at 7:19 AM, Frédéric THOMAS <
> > webdoublefx@hotmail.com>
> > > wrote:
> > >
> > > > 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: teotigraphixllc@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 <aharui@adobe.com>
> > wrote:
> > > > >
> > > > > >
> > > > > >
> > > > > > On 5/27/15, 4:16 PM, "Michael Schmalle" <teotigraphixllc@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
> > > > > >
> > > > > >
> > > >
> > > >
> >
> >
 		 	   		  
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message