That sounds great, thanks for working on that Josh! I was meaning to take a look into the same goog stuff for possible optimizations in reflection data and AMF, but I don't think any of that is in the same league as the improvement you just made (because they currently work in release build as-is). I am away on vacation for a week in a few days time, so probably won't get there until afterwards.
On Fri, Jan 17, 2020 at 9:59 AM Josh Tynjala <[email protected]> wrote: > Thank you, Harbs! Wrapping the variable name in a > goog.reflect.objectProperty() call works perfectly. This is exactly why I > started this thread, to see if anyone could suggest possible alternatives. > > Thankfully, we can keep the same simple data structure as before, and my > initial proposal with functions can be forgotten. In a release build, I can > see that goog.reflect.objectProperty() calls are replaced by a simple > string literal (containing the minified variable name), so we don't have to > worry about extra performance impact. > > -- > Josh Tynjala > Bowler Hat LLC <https://bowlerhat.dev> > > > On Wed, Jan 15, 2020 at 8:32 PM Harbs <[email protected]> wrote: > > > Sounds good! > > > > > > > https://github.com/google/closure-compiler/wiki/Type-Based-Property-Renaming > > < > > > https://github.com/google/closure-compiler/wiki/Type-Based-Property-Renaming > > > > > > > The function seems to be goog.reflect.objectProperty() > > > > I’m not sure exactly how it works though. > > > > > On Jan 16, 2020, at 1:37 AM, Greg Dove <[email protected]> wrote: > > > > > > actually just as another fyi, Harbs pointed out some intriguing goog > > > methods recently - I don't have an immediate reference to it sorry. One > > of > > > those seemed to allow for access to renamed names by wrapping the > > original > > > names in a 'magic' method that presumably GCC recognises (but > presumably > > > returns the name unchanged in debug mode) > > > > > > > > > On Thu, Jan 16, 2020 at 12:33 PM Greg Dove <[email protected]> > wrote: > > > > > >> reflection data has similar stuff to support release mode get/set for > > >> public vars. > > >> > > >> I did not look at MXML startup assignments like this, but it sounds > good > > >> to me. I don't know if it makes sense, but considering this is just > > startup > > >> assignments, could one function combine all of the startup assignments > > (in > > >> the same sequence as before)? > > >> > > >> > > >> On Thu, Jan 16, 2020 at 12:23 PM Josh Tynjala < > > [email protected]> > > >> wrote: > > >> > > >>> According to the commit linked below, the -warn-public-vars compiler > > >>> option > > >>> was added because setting a public var in MXML does not currently > work > > >>> properly in a release build. > > >>> > > >>> > > >>> > > > https://github.com/apache/royale-compiler/commit/eed5882ba935870a98ba4fe8cbf499e5d8344f60 > > >>> > > >>> In other words, this MXML code won't work if it's a public variable > and > > >>> not > > >>> a setter: > > >>> > > >>> <Component publicVar="value"/> > > >>> > > >>> For reference, the compiler currently writes the name of the public > > >>> variable as a string to the generated JS, like this: > > >>> > > >>> var data = [ > > >>> Component, > > >>> 1, > > >>> 'publicVar', > > >>> true, > > >>> 'value' > > >>> ] > > >>> > > >>> At runtime, it interprets this array of properties, and basically > runs > > >>> code > > >>> like this: > > >>> > > >>> comp['publicVar'] = 'value'; > > >>> > > >>> Since Closure compiler rewrites variable names during the > minification > > >>> process, this code keeps using the original name, but other code in > the > > >>> app > > >>> might start looking for a shorter variable name like "uB". This is > the > > >>> failure that we're warning about. > > >>> > > >>> I propose updating the code generated by the compiler to something > like > > >>> this instead: > > >>> > > >>> var data = [ > > >>> Component, > > >>> 1, > > >>> function(){ this.publicVar=true } > > >>> ] > > >>> > > >>> At runtime, the class that interprets MXML data will detect the > > function > > >>> and call it like this: > > >>> > > >>> func.apply(comp); > > >>> > > >>> Because this new code will no longer use a string, Closure can > rewrite > > the > > >>> property name with its minified version, just like in other parts of > > the > > >>> app, and we'll no longer need to warn on declarations of public > > variables. > > >>> > > >>> I have a working prototype for primitive values, like String, > Boolean, > > and > > >>> Number. Objects and Arrays follow a different path in the MXML data > > >>> interpreter, but I don't see why I wouldn't be able to handle those > > with a > > >>> similar approach. > > >>> > > >>> Thoughts? > > >>> > > >>> -- > > >>> Josh Tynjala > > >>> Bowler Hat LLC <https://bowlerhat.dev> > > >>> > > >> > > > > >
