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