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



´╗┐On 1/15/20, 3: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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-compiler%2Fcommit%2Feed5882ba935870a98ba4fe8cbf499e5d8344f60&amp;data=02%7C01%7Caharui%40adobe.com%7C65f0bac355d846d0a08008d79a11dfc3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637147273878230039&amp;sdata=u1q4bE5lzjBzUrxU2nwrBFr4V12fBOmUkY8giYK9948%3D&amp;reserved=0
    
    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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&amp;data=02%7C01%7Caharui%40adobe.com%7C65f0bac355d846d0a08008d79a11dfc3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637147273878230039&amp;sdata=exGdB05o%2FdvsX8%2BJ%2FE%2BrtqClAcZPg%2FE0NyrukfbdiuE%3D&amp;reserved=0>
    

Reply via email to