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