Some additional context, if anyone is interested. At the request of Harbs, I am currently investigating how we might remove @export from our generated JS code to improve the minimization even more. When I modified the compiler to skip emitting @export in some places, a release build of TourDeJewel was initially broken. When I added goog.reflect.objectProperty(), not only did it fix setting public variables in MXML, it also made that release build of TourDeJewel start working again.
-- Josh Tynjala Bowler Hat LLC <https://bowlerhat.dev> On Thu, Jan 16, 2020 at 12:59 PM Josh Tynjala <joshtynj...@bowlerhat.dev> 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 <harbs.li...@gmail.com> 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 <greg.d...@gmail.com> 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 <greg.d...@gmail.com> 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 < >> joshtynj...@bowlerhat.dev> >> >> 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> >> >>> >> >> >> >>
