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> > >>> > >> > >
