Clever idea, but I don't like it.  We are trying to reduce function call 
overhead and reduce download size, not increase it.  The reasons you are 
getting a public var warning is so that the app-dev has control over which 
members will have function call overhead. I don't think we should take that 
away from the app-dev.

Also, In many cases, you can just suppress the warning since you know the 
members are not being accessed from MXML.

My 2 cents,

´╗┐On 1/15/20, 3:23 PM, "Josh Tynjala" <> 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.
    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 = [
    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 = [
        function(){ this.publicVar=true }
    At runtime, the class that interprets MXML data will detect the function
    and call it like this:
    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.
    Josh Tynjala
    Bowler Hat LLC 

Reply via email to