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&data=02%7C01%7Caharui%40adobe.com%7C65f0bac355d846d0a08008d79a11dfc3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637147273878230039&sdata=u1q4bE5lzjBzUrxU2nwrBFr4V12fBOmUkY8giYK9948%3D&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&data=02%7C01%7Caharui%40adobe.com%7C65f0bac355d846d0a08008d79a11dfc3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637147273878230039&sdata=exGdB05o%2FdvsX8%2BJ%2FE%2BrtqClAcZPg%2FE0NyrukfbdiuE%3D&reserved=0>
