I should add one thing that I remembered soon after sending this. If we want to get rid of @export to ultimately remove public APIs that aren't used, a similar pattern will probably be necessary for setters too. Setters without @export get renamed too. Ultimately, we chose to use Closure compiler, and we need to write our code in the style that it demands. Right now, we have a bug because we weren't careful about that.
@Greg: Yes, I also thought of a single function could set all properties at once. It's certainly an alternative that is worth considering, and I think it would nicely avoid any overhead that Alex is worried about. @Harbs/@Greg: I'll check out goog.reflect.objectProperty(). If that works, we might be able to avoid the function call(s) completely. -- Josh Tynjala Bowler Hat LLC <https://bowlerhat.dev> On Wed, Jan 15, 2020 at 3:22 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> >
