You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@royale.apache.org by Josh Tynjala <jo...@bowlerhat.dev> on 2020/01/15 23:22:51 UTC
MXML and warn-public vars
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>
Re: MXML and warn-public vars
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Simple is usually best. Changing what is currently a simple data stream into something that cannot be easily seen in the debugger is adding complexity. I'm pretty sure we can control the renaming in the Closure Compiler without changing how we write our code for them. We are already doing something like that for modules.
It is one thing to write code that Closure Compiler can minify, it is another to make our code harder to work with because we are afraid to understand an open source compiler.
Fix the problem in the right place, please. Please also take the time to understand how the compiler works before guessing at solutions.
Thanks,
-Alex
On 1/16/20, 8:53 AM, "Josh Tynjala" <jo...@bowlerhat.dev> wrote:
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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C31b3966338eb41f142fc08d79aa4a19f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637147904190228714&sdata=tFTMpbJnM6k27dJWRQQj7mKIcNCLbxcopVzfL5bTILg%3D&reserved=0>
On Wed, Jan 15, 2020 at 3:22 PM Josh Tynjala <jo...@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%7C31b3966338eb41f142fc08d79aa4a19f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637147904190228714&sdata=WnWxyfaeoLZAGtGD%2BxRmw9XtyxZrA8PRozvCTle%2B018%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%7C31b3966338eb41f142fc08d79aa4a19f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637147904190228714&sdata=tFTMpbJnM6k27dJWRQQj7mKIcNCLbxcopVzfL5bTILg%3D&reserved=0>
>
Re: MXML and warn-public vars
Posted by Josh Tynjala <jo...@bowlerhat.dev>.
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 <jo...@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>
>
Re: MXML and warn-public vars
Posted by Harbs <ha...@gmail.com>.
I’m not sure that this increases function call overhead or code size. I suspect it will have the opposite effect.
Basically, to avoid function calls in MXML structure, we’re requiring getters and setters in every public member. That results in two function calls in every class instantiation per member. That’s whether or not it’s actually used in MXML.
Theoretically, if MXML classes are instantiated my times (such as in an ItemRenderer), the function calls might have an effect, but I’m still skeptical that it would have a negative net effect on performance. Yes. Functions in JS are slower than getter access, but getters are also slower than direct property access. I suspect that property getters are used many more times in code than MXML resolution. [edit to the above — which is fastest depends on browsers and it’s totally non-conclusive. Simple fuinctions might even be fastest in some browser (hello Firefox) due to inlining. I’m including a number of jsperf links at the end of this message. Take a look…]
It’s also worth noting that browser vendors are under pressure to make function calls as fast as possible due to the recent trend towards functional programming.
My experience has been that avoiding public vars is a pain and we want to make developers’ lives easier and not harder.
Without empirical evidence that function calls in MXML structure will have a bad net effect my preferences are as follows:
1. See if there’s some way we can keep a simple structure and use the goog.reflect functions.
2. Use function access in MXML to enable use of public vars.
3. Keep it the way it is.
The only question I have is how this effects modules? Wouldn’t modules have problems with public vars too?
I wonder if it makes sense to have two compilations of libraries; one that supports max minification, and another which supports modules. (unless it’s possible to deal with this at app compile time)
Harbs
https://jsperf.com/object-defineproperty-vs-definegetter-vs-normal/35 <https://jsperf.com/object-defineproperty-vs-definegetter-vs-normal/35>
https://jsperf.com/312319sakd/2 <https://jsperf.com/312319sakd/2>
https://jsperf.com/312319sakd <https://jsperf.com/312319sakd>
https://jsperf.com/getter-performance <https://jsperf.com/getter-performance>
> On Jan 16, 2020, at 8:31 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> We've been down this road before. I would rather warn folks to change their code so it will be as small and fast as possible. Others don't seem to care and would rather not change their code. The end-of-the-road for the "must mimic Flex" is that we will rarely read and write variables/properties directly. All access of Objects and dynamics will have to go through a runtime type checking that emulates Flash in case the object turns out to be XML or Proxy.
>
> Go ahead and code it up, but please make it an option. In the framework, we should just suppress the warning where it won't be used in MXML. I will continue to advise the people I work with to make modifications to their code.
>
> -Alex
>
> On 1/15/20, 9:44 PM, "Greg Dove" <greg.dove@gmail.com <ma...@gmail.com>> wrote:
>
> Am I misunderstanding or does this fix a usability issue with mxml and
> public vars?
> If it is fixing something that does not work, then presumably it only
> 'costs' for people who want that thing to work (public var assignments in
> mxml instances?) and not for others. That seems like the app-dev still has
> the 'choice' so long as they are aware of it and care.
> Or is there an alternative for the developer who wants that to work exactly
> like it does in Flex?
>
> If this does fix a usability issue, then I don't understand why it should
> always be 'smaller' (and possibly less reliable) that is the threshold for
> decision making. We presumably need to apply a balance that we can be sure
> represents what users actually want.
>
> 'We are trying to reduce function call overhead and reduce download size,
> not increase it.'
>
> It would be good to actually test that, function call overhead in js is
> much lower than what it was in swf, but perhaps this still would be slower
> I guess - perhaps not if all startup assignments were combined into one
> function. In terms of 'size', the assignment name would be renamed/minified
> and possibly avoid a string table entry, and the extra 'function(){' would
> be a very common sequence at gzip level I expect (it would still show up as
> extra in the js-release length but perhaps could be close to neutral or
> even smaller at gzip level).
>
> This idea sounds to be worth exploring to me. The goog.reflect methods also
> sound like they might possibly offer some other approaches as well though,
> if they provide another way to address the same issue.
>
>
>
> On Thu, Jan 16, 2020 at 5:42 PM Alex Harui <ah...@adobe.com.invalid> wrote:
>
>> 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" <jo...@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%7Cff845c64c5ae4280b9f208d79a4728cd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637147502737629685&sdata=npJLZs0oDyWiVzlOCP1OxJKpLesAtDqrwx%2BygOVENXE%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-compiler%2Fcommit%2Feed5882ba935870a98ba4fe8cbf499e5d8344f60&data=02%7C01%7Caharui%40adobe.com%7Cff845c64c5ae4280b9f208d79a4728cd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637147502737629685&sdata=npJLZs0oDyWiVzlOCP1OxJKpLesAtDqrwx%2BygOVENXE%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%7Cff845c64c5ae4280b9f208d79a4728cd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637147502737629685&sdata=9TZ66rVPqQH1R7cMBHYtuKS18nQ7wtgE0Sn9PGujmPE%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7Cff845c64c5ae4280b9f208d79a4728cd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637147502737629685&sdata=9TZ66rVPqQH1R7cMBHYtuKS18nQ7wtgE0Sn9PGujmPE%3D&reserved=0>
Re: MXML and warn-public vars
Posted by Alex Harui <ah...@adobe.com.INVALID>.
We've been down this road before. I would rather warn folks to change their code so it will be as small and fast as possible. Others don't seem to care and would rather not change their code. The end-of-the-road for the "must mimic Flex" is that we will rarely read and write variables/properties directly. All access of Objects and dynamics will have to go through a runtime type checking that emulates Flash in case the object turns out to be XML or Proxy.
Go ahead and code it up, but please make it an option. In the framework, we should just suppress the warning where it won't be used in MXML. I will continue to advise the people I work with to make modifications to their code.
-Alex
On 1/15/20, 9:44 PM, "Greg Dove" <gr...@gmail.com> wrote:
Am I misunderstanding or does this fix a usability issue with mxml and
public vars?
If it is fixing something that does not work, then presumably it only
'costs' for people who want that thing to work (public var assignments in
mxml instances?) and not for others. That seems like the app-dev still has
the 'choice' so long as they are aware of it and care.
Or is there an alternative for the developer who wants that to work exactly
like it does in Flex?
If this does fix a usability issue, then I don't understand why it should
always be 'smaller' (and possibly less reliable) that is the threshold for
decision making. We presumably need to apply a balance that we can be sure
represents what users actually want.
'We are trying to reduce function call overhead and reduce download size,
not increase it.'
It would be good to actually test that, function call overhead in js is
much lower than what it was in swf, but perhaps this still would be slower
I guess - perhaps not if all startup assignments were combined into one
function. In terms of 'size', the assignment name would be renamed/minified
and possibly avoid a string table entry, and the extra 'function(){' would
be a very common sequence at gzip level I expect (it would still show up as
extra in the js-release length but perhaps could be close to neutral or
even smaller at gzip level).
This idea sounds to be worth exploring to me. The goog.reflect methods also
sound like they might possibly offer some other approaches as well though,
if they provide another way to address the same issue.
On Thu, Jan 16, 2020 at 5:42 PM Alex Harui <ah...@adobe.com.invalid> wrote:
> 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" <jo...@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%7Cff845c64c5ae4280b9f208d79a4728cd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637147502737629685&sdata=npJLZs0oDyWiVzlOCP1OxJKpLesAtDqrwx%2BygOVENXE%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%7Cff845c64c5ae4280b9f208d79a4728cd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637147502737629685&sdata=9TZ66rVPqQH1R7cMBHYtuKS18nQ7wtgE0Sn9PGujmPE%3D&reserved=0
> >
>
>
>
Re: MXML and warn-public vars
Posted by Greg Dove <gr...@gmail.com>.
Am I misunderstanding or does this fix a usability issue with mxml and
public vars?
If it is fixing something that does not work, then presumably it only
'costs' for people who want that thing to work (public var assignments in
mxml instances?) and not for others. That seems like the app-dev still has
the 'choice' so long as they are aware of it and care.
Or is there an alternative for the developer who wants that to work exactly
like it does in Flex?
If this does fix a usability issue, then I don't understand why it should
always be 'smaller' (and possibly less reliable) that is the threshold for
decision making. We presumably need to apply a balance that we can be sure
represents what users actually want.
'We are trying to reduce function call overhead and reduce download size,
not increase it.'
It would be good to actually test that, function call overhead in js is
much lower than what it was in swf, but perhaps this still would be slower
I guess - perhaps not if all startup assignments were combined into one
function. In terms of 'size', the assignment name would be renamed/minified
and possibly avoid a string table entry, and the extra 'function(){' would
be a very common sequence at gzip level I expect (it would still show up as
extra in the js-release length but perhaps could be close to neutral or
even smaller at gzip level).
This idea sounds to be worth exploring to me. The goog.reflect methods also
sound like they might possibly offer some other approaches as well though,
if they provide another way to address the same issue.
On Thu, Jan 16, 2020 at 5:42 PM Alex Harui <ah...@adobe.com.invalid> wrote:
> 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" <jo...@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
> >
>
>
>
Re: MXML and warn-public vars
Posted by Alex Harui <ah...@adobe.com.INVALID>.
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" <jo...@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>
Re: MXML and warn-public vars
Posted by Josh Tynjala <jo...@bowlerhat.dev>.
I'm not sure that I understand how this solution takes control away from
anyone. It fixes a bug when a public variable is renamed, but at the same
time, it preserves the existing behavior for things that are not renamed.
- Josh
On Thursday, January 16, 2020, Alex Harui <ah...@adobe.com.invalid> wrote:
> I'm not surprised that this change fixed a problem caused by removing
@export. This is not a question about the technical accuracy of your work,
which is always very good. This just doesn't feel like the right
solution. Maybe we should start by agreeing on facts and then goals and
then discuss solutions. This solution seems to take control of the output
away from folks who will want different output and is solving a specific
scenario and not the general problem in a less optimal way.
>
> Here are some facts that come to mind, not a complete list.
>
> 1) An export does not prevent renaming. It builds an alias. All
references within the set of sources to be minified are renamed.
> 2) Closure's export mechanism only works on non-scalars (Object, Arrays,
Functions) and not Number, String, Boolean because non-scalars are
pass-by-reference instead of pass-by-value
> 3) The Closure Compiler is open source and designed to be extended
> 4) Use of goog.reflect.objectProperty is not necessarily the only way to
control renaming. It is the way recommended by Google for those who can't
extend the compiler. We are not constrained to modify our output because
we have control over the compiler.
> 5) The compiler knows things about how properties were accessed. That
information is lost in the output in many cases. Therefore, it should be
better to inform the Google minifier directly from the Royale compiler,
instead of leaving hints in the output.
> 6) All getter/setters are not renamed, but are not exported.
> 7) We are pretty close to allowing renaming across modules. It was
working for a while, but a scenario popped up that isn't currently
handled. We can pre-load the Closure renamer with a name map.
>
> These are hypotheses, and not proven facts.
> 8) The big gain from not exporting everything is in dead code removal
instead of shorter variable names
> 9) Renaming can complicate and slow serialization/deserialization
>
> IMO, we want to be heading in the direction of A) allowing control over
what gets renamed, B) capturing information from the compiler, C)
controlling the set of renames and exports directly, not through the output.
>
> My 2 cents,
> -Alex
>
>
> On 1/16/20, 2:48 PM, "Josh Tynjala" <jo...@bowlerhat.dev> wrote:
>
> Some additional context, if anyone is interested.
>
> At the request of Harbs, I am currently investigating how we might
remove
> @export from our generated JS code to improve the minimization even
more.
> When I modified the compiler to skip emitting @export in some places,
a
> release build of TourDeJewel was initially broken. When I added
> goog.reflect.objectProperty(), not only did it fix setting public
variables
> in MXML, it also made that release build of TourDeJewel start working
again.
>
> --
> Josh Tynjala
> Bowler Hat LLC <
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7Cc060c7977c184a07aa2708d79ad6357a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148117120345421&sdata=ysm%2FJ2FfEK9jKlj4gND5LIFLihlaP6pHZYs0eueIihs%3D&reserved=0
>
>
>
> On Thu, Jan 16, 2020 at 12:59 PM Josh Tynjala <
joshtynjala@bowlerhat.dev>
> wrote:
>
> > Thank you, Harbs! Wrapping the variable name in a
> > goog.reflect.objectProperty() call works perfectly. This is exactly
why I
> > started this thread, to see if anyone could suggest possible
alternatives.
> >
> > Thankfully, we can keep the same simple data structure as before,
and my
> > initial proposal with functions can be forgotten. In a release
build, I can
> > see that goog.reflect.objectProperty() calls are replaced by a
simple
> > string literal (containing the minified variable name), so we don't
have to
> > worry about extra performance impact.
> >
> > --
> > Josh Tynjala
> > Bowler Hat LLC <
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7Cc060c7977c184a07aa2708d79ad6357a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148117120355415&sdata=6fT85c%2FQJ8aXEYf%2FQgZ%2BcoEj1%2F0%2BfmskfdvHXuLeXOg%3D&reserved=0
>
> >
> >
> > On Wed, Jan 15, 2020 at 8:32 PM Harbs <ha...@gmail.com> wrote:
> >
> >> Sounds good!
> >>
> >>
> >>
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FType-Based-Property-Renaming&data=02%7C01%7Caharui%40adobe.com%7Cc060c7977c184a07aa2708d79ad6357a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148117120355415&sdata=ncKq3dWJbDBJB6EylRMugca0Ck512sngA6O6KQ9IupQ%3D&reserved=0
> >> <
> >>
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FType-Based-Property-Renaming&data=02%7C01%7Caharui%40adobe.com%7Cc060c7977c184a07aa2708d79ad6357a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148117120355415&sdata=ncKq3dWJbDBJB6EylRMugca0Ck512sngA6O6KQ9IupQ%3D&reserved=0
> >> >
> >>
> >> The function seems to be goog.reflect.objectProperty()
> >>
> >> I’m not sure exactly how it works though.
> >>
> >> > On Jan 16, 2020, at 1:37 AM, Greg Dove <gr...@gmail.com>
wrote:
> >> >
> >> > actually just as another fyi, Harbs pointed out some intriguing
goog
> >> > methods recently - I don't have an immediate reference to it
sorry. One
> >> of
> >> > those seemed to allow for access to renamed names by wrapping the
> >> original
> >> > names in a 'magic' method that presumably GCC recognises (but
presumably
> >> > returns the name unchanged in debug mode)
> >> >
> >> >
> >> > On Thu, Jan 16, 2020 at 12:33 PM Greg Dove <gr...@gmail.com>
wrote:
> >> >
> >> >> 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 <
> >> joshtynjala@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%7Cc060c7977c184a07aa2708d79ad6357a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148117120355415&sdata=a3kRb8bAWJfR%2BiTmsdk11%2FfvdXgSyYrJXDFfBY7nSok%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%7Cc060c7977c184a07aa2708d79ad6357a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148117120355415&sdata=6fT85c%2FQJ8aXEYf%2FQgZ%2BcoEj1%2F0%2BfmskfdvHXuLeXOg%3D&reserved=0
>
> >> >>>
> >> >>
> >>
> >>
>
>
>
--
--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>
Re: MXML and warn-public vars
Posted by Josh Tynjala <jo...@bowlerhat.dev>.
That's a good point about checking whether Flex could do that. I think that
the compiler may need to know the state names at compile-time, but binding
is generally considered a run-time thing.
--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>
On Wed, Feb 5, 2020 at 12:54 PM Greg Dove <gr...@gmail.com> wrote:
> Did that work in Flex for states? I seem to remember issues with trying to
> use constants with states, although maybe it was with other parts of how
> states are used.
>
> The issue is that you can have things like:
>
> <MyComp x.All="25" x.Completed="100" /> (I have never tried this with
> uppercase first letter in state names, but presume it works)
>
> And I don't think there is any way to get the state variations from the
> constant declarations in that case.
>
> For constant bindings in general...I can try to find some old code I worked
> on for converting static constant bindings with primitive values like that
> to inlined value assignments (which removes them from the binding data and
> puts them into the normal mxmldescriptor startup assignments for the
> instances).
>
>
>
>
> On Thu, Feb 6, 2020 at 9:38 AM Josh Tynjala <jo...@bowlerhat.dev>
> wrote:
>
> > My initial implementation will probably all or nothing, in terms of
> > renaming, but we can revisit after to add more fine-grained control, if
> > necessary.
> >
> > I'll try to take a look at that constant issue when I get a chance.
> >
> > --
> > Josh Tynjala
> > Bowler Hat LLC <https://bowlerhat.dev>
> >
> >
> > On Wed, Feb 5, 2020 at 12:23 PM Harbs <ha...@gmail.com> wrote:
> >
> > > I hope there will be an option to prevent specific variables.
> > >
> > > The obvious ones would be ones used in MXML.
> > >
> > > Other candidates would be classes which correspond to JSON so the
> classes
> > > can be constructed with bracket notation. I’m not sure of the best way
> to
> > > declare a class for that. Maybe abusing “dynamic” classes?
> > >
> > > FWIW, I also noticed a bug recently that I didn’t log:
> > >
> > > In todomvc there’s the following in the router branch:
> > >
> > > <j:states>
> > > <js:State name="All"/>
> > > <js:State name="Active"/>
> > > <js:State name="Completed"/>
> > > </j:states>
> > >
> > > I tried using constants like so, and it failed. (At runtime the values
> > > were “ALL”,”ACTIVE_FILTER” and “COMPLETED_FILTER”.)
> > > <j:states>
> > > <js:State name="{TodoModel.ALL}"/>
> > > <js:State name="{TodoModel.ACTIVE_FILTER}"/>
> > > <js:State name="{TodoModel.COMPLETED_FILTER}"/>
> > > </j:states>
> > >
> > >
> > > > On Feb 5, 2020, at 9:41 PM, Josh Tynjala <jo...@bowlerhat.dev>
> > > wrote:
> > > >
> > > > Thank you for the tips, Alex. Much appreciated. With your help, I've
> > > > determined how to use Closure compiler's Java API to prevent the
> > renaming
> > > > of a specific public variable that has not been @export-ed. Now, I
> > should
> > > > be able to expand this prototype to a full version that prevents the
> > > > renaming of all public variables.
> > > >
> > > > --
> > > > Josh Tynjala
> > > > Bowler Hat LLC <https://bowlerhat.dev>
> > > >
> > > >
> > > > On Sun, Jan 19, 2020 at 4:58 PM Alex Harui <aharui@adobe.com.invalid
> >
> > > wrote:
> > > >
> > > >> In response to your prior post, the reason I am saying it removes
> > > control
> > > >> is because I didn't see any option to not have the compiler output
> > > >> goog.reflect.objectProperty and I'm not clear everyone will
> want/need
> > > it.
> > > >>
> > > >> Regarding how to control Closure Compiler's renaming, the details
> > might
> > > be
> > > >> changing because I believe I saw that Google refactored the renamer.
> > > At a
> > > >> high-level, you probably know most of this, but for other folks
> > reading,
> > > >> the Closure Compiler is a set of Java Classes that form a series of
> > > >> Compiler Passes. Each Pass takes information (sometimes source,
> > > sometimes
> > > >> the AST, sometimes other information, and modifies the AST. IIRC, a
> > > final
> > > >> pass generates the output. There might be more than one pass for
> > > output.
> > > >>
> > > >> The renaming pass we currently use can output as well as accept a
> file
> > > of
> > > >> rename mappings. I’m confident we can subclass or modify and
> replace
> > > the
> > > >> renaming pass and feed it a set of mappings. If you look in the
> > > >> royale-compiler source, we've already done this for some other
> passes.
> > > >> Look through the Closure compiler source for what happens to the
> > > compiler
> > > >> options:
> > > >>
> > > >> --variable_map_input_file
> > > >> --property_map_input_file
> > > >>
> > > >> You can build examples/mxroyale/TourDeFlexModules which outputs
> these
> > > >> files to see what is in them.
> > > >>
> > > >>
> > > >> We should also see if we can agree on the scenarios and likelihood
> of
> > > >> property access "by name". I can quickly think of:
> > > >>
> > > >> A) MXML setting properties by reference (high usage)
> > > >> B) MXML setting properties by value (high usage)
> > > >> C) Serializers/Deserializers (moderate usage)
> > > >> D) [] bracket access by Literal (occasional usage)
> > > >> E) [] bracket access by String Variable (occasional usage)
> > > >> F) [] bracket access by Expression (infrequent usage)
> > > >>
> > > >> Exports can solve A. The compiler can easily detect D & E and
> prevent
> > > >> renaming. For C, we "could" autogenerate exports for any classes
> with
> > > >> [RemoteClass] metadata or autogenerate getter/setters.
> > > >>
> > > >> To me, the only difficult case is F and it will rarely happen.
> Maybe
> > we
> > > >> can detect those and warn on that.
> > > >>
> > > >> Of course, I could be wrong...
> > > >> -Alex
> > > >>
> > > >>
> > > >> On 1/17/20, 10:08 AM, "Josh Tynjala" <jo...@bowlerhat.dev>
> > > wrote:
> > > >>
> > > >> Comments inline.
> > > >>
> > > >> On Thursday, January 16, 2020, Alex Harui
> <aharui@adobe.com.invalid
> > >
> > > >> wrote:
> > > >>> Maybe we should start by agreeing on facts and then goals and then
> > > >> discuss solutions.
> > > >>
> > > >> Yes, I think that's a good place to start.
> > > >>
> > > >>>
> > > >>> Here are some facts that come to mind, not a complete list.
> > > >>>
> > > >>> 1) An export does not prevent renaming. It builds an alias. All
> > > >> references within the set of sources to be minified are renamed.
> > > >>
> > > >> Agreed.
> > > >>
> > > >>> 2) Closure's export mechanism only works on non-scalars (Object,
> > > >> Arrays,
> > > >> Functions) and not Number, String, Boolean because non-scalars
> are
> > > >> pass-by-reference instead of pass-by-value
> > > >>
> > > >> Agreed.
> > > >>
> > > >>> 3) The Closure Compiler is open source and designed to be extended
> > > >>
> > > >> Agreed.
> > > >>
> > > >>> 4) Use of goog.reflect.objectProperty is not necessarily the only
> > > >> way to
> > > >> control renaming. It is the way recommended by Google for those
> > who
> > > >> can't
> > > >> extend the compiler. We are not constrained to modify our output
> > > >> because
> > > >> we have control over the compiler.
> > > >>
> > > >> Could you share some details how we might have more control over
> > > >> Closure
> > > >> compiler's renaming? It sounds like you know, at least somewhat,
> > how
> > > >> to use
> > > >> its lower-level Java APIs, but you've never shared the details
> when
> > > >> you've
> > > >> mentioned them in this thread or in the past.
> > > >>
> > > >> I should add that I've personally tried to research this topic
> > > myself,
> > > >> but
> > > >> I had a very hard time finding any information that wasn't just
> > > someone
> > > >> explaining to a JS developer that they needed to modify their JS
> > > code.
> > > >> I
> > > >> eventually couldn't justify spending more time to keep looking.
> > > >>
> > > >>> 5) The compiler knows things about how properties were accessed.
> > > >> That
> > > >> information is lost in the output in many cases. Therefore, it
> > > should
> > > >> be
> > > >> better to inform the Google minifier directly from the Royale
> > > compiler,
> > > >> instead of leaving hints in the output.
> > > >>
> > > >> Agreed. I'm personally not fully convinced that the Royale
> compiler
> > > has
> > > >> enough information for dynamic stuff (like for serialization with
> > > type
> > > >> Object), but that may be due to ignorance about Closure
> compiler's
> > > >> capabilities. Even without knowing how it works, I can imagine
> how
> > it
> > > >> might
> > > >> be relatively easy to prevent renaming of public variables, but
> the
> > > >> dynamic
> > > >> stuff is trickier. For the dynamic stuff, maybe it's just a
> matter
> > of
> > > >> Closure detecting when a variable is typed as Object, and then it
> > can
> > > >> switch to ["string"] syntax on its own (instead of us doing it in
> > the
> > > >> debug
> > > >> build, like with -js-dynamic-access-unknown-members).
> > > >>
> > > >>> 7) We are pretty close to allowing renaming across modules. It was
> > > >> working for a while, but a scenario popped up that isn't
> currently
> > > >> handled. We can pre-load the Closure renamer with a name map.
> > > >>
> > > >> I haven't looked in detail at the module implementation and don't
> > > plan
> > > >> to,
> > > >> but I understand it well enough at a high level to say "agreed"
> > here
> > > >> too
> > > >>
> > > >>>
> > > >>> These are hypotheses, and not proven facts.
> > > >>> 8) The big gain from not exporting everything is in dead code
> removal
> > > >> instead of shorter variable names
> > > >>
> > > >> Agreed, personally. It seems like others have expressed interest
> in
> > > >> both,
> > > >> though. I hope that they'll be willing to prioriitze dead code
> > > removal,
> > > >> since it will probably have the bigger impact (my own tests
> > removing
> > > >> @export have been promising in this regard).
> > > >>
> > > >>> 9) Renaming can complicate and slow serialization/deserialization
> > > >>
> > > >> Agreed, and this is the harder portion to get working, I think.
> > > >>
> > > >> However, if release builds didn't rename public variables, and
> also
> > > >> didn't
> > > >> rename dynamic accesses, that would remove my biggest frustration
> > > with
> > > >> how
> > > >> ActionScript works in Royale/JS compared to SWF. If both kept
> their
> > > >> original names, things that feel broken today would "just work"
> > > again.
> > > >>
> > > >>>
> > > >>> IMO, we want to be heading in the direction of A) allowing control
> > > >> over
> > > >> what gets renamed
> > > >>
> > > >> Agreed, but as I said before, I think that dead code removal will
> > > have
> > > >> more
> > > >> impact than control over renaming, so if it's one or the other,
> I'm
> > > >> okay
> > > >> with no control over renaming.
> > > >>
> > > >>> B) capturing information from the compiler,
> > > >>> C) controlling the set of renames and exports directly, not through
> > > >> the
> > > >> output.
> > > >>
> > > >> Agreed, being able to pass information Closure compiler on the
> Java
> > > >> side
> > > >> would be better. than through the JS output
> > > >>
> > > >>
> > > >>>
> > > >>> My 2 cents,
> > > >>> -Alex
> > > >>>
> > > >>>
> > > >>> On 1/16/20, 2:48 PM, "Josh Tynjala" <jo...@bowlerhat.dev>
> > > >> wrote:
> > > >>>
> > > >>> Some additional context, if anyone is interested.
> > > >>>
> > > >>> At the request of Harbs, I am currently investigating how we
> > > >> might
> > > >> remove
> > > >>> @export from our generated JS code to improve the minimization
> > > >> even
> > > >> more.
> > > >>> When I modified the compiler to skip emitting @export in some
> > > >> places,
> > > >> a
> > > >>> release build of TourDeJewel was initially broken. When I added
> > > >>> goog.reflect.objectProperty(), not only did it fix setting
> public
> > > >> variables
> > > >>> in MXML, it also made that release build of TourDeJewel start
> > > >> working
> > > >> again.
> > > >>>
> > > >>> --
> > > >>> Josh Tynjala
> > > >>> Bowler Hat LLC <
> > > >>
> > > >>
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C1e9c2c4ae9d049b2896708d79b7843c7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148813154391097&sdata=8T%2B4UIVZrakKMBkAs2qOcwalYaCVJuMxHMKPYTnbvxM%3D&reserved=0
> > > >>>
> > > >>>
> > > >>>
> > > >>> On Thu, Jan 16, 2020 at 12:59 PM Josh Tynjala <
> > > >> joshtynjala@bowlerhat.dev>
> > > >>> wrote:
> > > >>>
> > > >>>> Thank you, Harbs! Wrapping the variable name in a
> > > >>>> goog.reflect.objectProperty() call works perfectly. This is
> > > >> exactly
> > > >> why I
> > > >>>> started this thread, to see if anyone could suggest possible
> > > >> alternatives.
> > > >>>>
> > > >>>> Thankfully, we can keep the same simple data structure as
> > > >> before,
> > > >> and my
> > > >>>> initial proposal with functions can be forgotten. In a release
> > > >> build, I can
> > > >>>> see that goog.reflect.objectProperty() calls are replaced by a
> > > >> simple
> > > >>>> string literal (containing the minified variable name), so we
> > > >> don't
> > > >> have to
> > > >>>> worry about extra performance impact.
> > > >>>>
> > > >>>> --
> > > >>>> Josh Tynjala
> > > >>>> Bowler Hat LLC <
> > > >>
> > > >>
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C1e9c2c4ae9d049b2896708d79b7843c7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148813154391097&sdata=8T%2B4UIVZrakKMBkAs2qOcwalYaCVJuMxHMKPYTnbvxM%3D&reserved=0
> > > >>>
> > > >>>>
> > > >>>>
> > > >>>> On Wed, Jan 15, 2020 at 8:32 PM Harbs <ha...@gmail.com>
> > > >> wrote:
> > > >>>>
> > > >>>>> Sounds good!
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>
> > > >>
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FType-Based-Property-Renaming&data=02%7C01%7Caharui%40adobe.com%7C1e9c2c4ae9d049b2896708d79b7843c7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148813154391097&sdata=IzzY7%2BhSQ9iQr9GIKd16XD%2FfGwxB50aN6J0Mzb%2BEcWA%3D&reserved=0
> > > >>>>> <
> > > >>>>>
> > > >>
> > > >>
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FType-Based-Property-Renaming&data=02%7C01%7Caharui%40adobe.com%7C1e9c2c4ae9d049b2896708d79b7843c7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148813154391097&sdata=IzzY7%2BhSQ9iQr9GIKd16XD%2FfGwxB50aN6J0Mzb%2BEcWA%3D&reserved=0
> > > >>>>>>
> > > >>>>>
> > > >>>>> The function seems to be goog.reflect.objectProperty()
> > > >>>>>
> > > >>>>> I’m not sure exactly how it works though.
> > > >>>>>
> > > >>>>>> On Jan 16, 2020, at 1:37 AM, Greg Dove <greg.dove@gmail.com
> > > >>>
> > > >> wrote:
> > > >>>>>>
> > > >>>>>> actually just as another fyi, Harbs pointed out some
> > > >> intriguing
> > > >> goog
> > > >>>>>> methods recently - I don't have an immediate reference to it
> > > >> sorry. One
> > > >>>>> of
> > > >>>>>> those seemed to allow for access to renamed names by
> > > >> wrapping the
> > > >>>>> original
> > > >>>>>> names in a 'magic' method that presumably GCC recognises
> > > >> (but
> > > >> presumably
> > > >>>>>> returns the name unchanged in debug mode)
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> On Thu, Jan 16, 2020 at 12:33 PM Greg Dove <
> > > >> greg.dove@gmail.com>
> > > >> wrote:
> > > >>>>>>
> > > >>>>>>> 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 <
> > > >>>>> joshtynjala@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%7C1e9c2c4ae9d049b2896708d79b7843c7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148813154391097&sdata=aA3JAnaQuU1GrF%2B4vmTo1Lhn38gDM4UtG2%2FdbmwBnjQ%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%7C1e9c2c4ae9d049b2896708d79b7843c7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148813154391097&sdata=8T%2B4UIVZrakKMBkAs2qOcwalYaCVJuMxHMKPYTnbvxM%3D&reserved=0
> > > >>>
> > > >>>>>>>>
> > > >>>>>>>
> > > >>>>>
> > > >>>>>
> > > >>>
> > > >>>
> > > >>>
> > > >>
> > > >>
> > > >>
> > >
> > >
> >
>
Re: MXML and warn-public vars
Posted by Greg Dove <gr...@gmail.com>.
Did that work in Flex for states? I seem to remember issues with trying to
use constants with states, although maybe it was with other parts of how
states are used.
The issue is that you can have things like:
<MyComp x.All="25" x.Completed="100" /> (I have never tried this with
uppercase first letter in state names, but presume it works)
And I don't think there is any way to get the state variations from the
constant declarations in that case.
For constant bindings in general...I can try to find some old code I worked
on for converting static constant bindings with primitive values like that
to inlined value assignments (which removes them from the binding data and
puts them into the normal mxmldescriptor startup assignments for the
instances).
On Thu, Feb 6, 2020 at 9:38 AM Josh Tynjala <jo...@bowlerhat.dev>
wrote:
> My initial implementation will probably all or nothing, in terms of
> renaming, but we can revisit after to add more fine-grained control, if
> necessary.
>
> I'll try to take a look at that constant issue when I get a chance.
>
> --
> Josh Tynjala
> Bowler Hat LLC <https://bowlerhat.dev>
>
>
> On Wed, Feb 5, 2020 at 12:23 PM Harbs <ha...@gmail.com> wrote:
>
> > I hope there will be an option to prevent specific variables.
> >
> > The obvious ones would be ones used in MXML.
> >
> > Other candidates would be classes which correspond to JSON so the classes
> > can be constructed with bracket notation. I’m not sure of the best way to
> > declare a class for that. Maybe abusing “dynamic” classes?
> >
> > FWIW, I also noticed a bug recently that I didn’t log:
> >
> > In todomvc there’s the following in the router branch:
> >
> > <j:states>
> > <js:State name="All"/>
> > <js:State name="Active"/>
> > <js:State name="Completed"/>
> > </j:states>
> >
> > I tried using constants like so, and it failed. (At runtime the values
> > were “ALL”,”ACTIVE_FILTER” and “COMPLETED_FILTER”.)
> > <j:states>
> > <js:State name="{TodoModel.ALL}"/>
> > <js:State name="{TodoModel.ACTIVE_FILTER}"/>
> > <js:State name="{TodoModel.COMPLETED_FILTER}"/>
> > </j:states>
> >
> >
> > > On Feb 5, 2020, at 9:41 PM, Josh Tynjala <jo...@bowlerhat.dev>
> > wrote:
> > >
> > > Thank you for the tips, Alex. Much appreciated. With your help, I've
> > > determined how to use Closure compiler's Java API to prevent the
> renaming
> > > of a specific public variable that has not been @export-ed. Now, I
> should
> > > be able to expand this prototype to a full version that prevents the
> > > renaming of all public variables.
> > >
> > > --
> > > Josh Tynjala
> > > Bowler Hat LLC <https://bowlerhat.dev>
> > >
> > >
> > > On Sun, Jan 19, 2020 at 4:58 PM Alex Harui <ah...@adobe.com.invalid>
> > wrote:
> > >
> > >> In response to your prior post, the reason I am saying it removes
> > control
> > >> is because I didn't see any option to not have the compiler output
> > >> goog.reflect.objectProperty and I'm not clear everyone will want/need
> > it.
> > >>
> > >> Regarding how to control Closure Compiler's renaming, the details
> might
> > be
> > >> changing because I believe I saw that Google refactored the renamer.
> > At a
> > >> high-level, you probably know most of this, but for other folks
> reading,
> > >> the Closure Compiler is a set of Java Classes that form a series of
> > >> Compiler Passes. Each Pass takes information (sometimes source,
> > sometimes
> > >> the AST, sometimes other information, and modifies the AST. IIRC, a
> > final
> > >> pass generates the output. There might be more than one pass for
> > output.
> > >>
> > >> The renaming pass we currently use can output as well as accept a file
> > of
> > >> rename mappings. I’m confident we can subclass or modify and replace
> > the
> > >> renaming pass and feed it a set of mappings. If you look in the
> > >> royale-compiler source, we've already done this for some other passes.
> > >> Look through the Closure compiler source for what happens to the
> > compiler
> > >> options:
> > >>
> > >> --variable_map_input_file
> > >> --property_map_input_file
> > >>
> > >> You can build examples/mxroyale/TourDeFlexModules which outputs these
> > >> files to see what is in them.
> > >>
> > >>
> > >> We should also see if we can agree on the scenarios and likelihood of
> > >> property access "by name". I can quickly think of:
> > >>
> > >> A) MXML setting properties by reference (high usage)
> > >> B) MXML setting properties by value (high usage)
> > >> C) Serializers/Deserializers (moderate usage)
> > >> D) [] bracket access by Literal (occasional usage)
> > >> E) [] bracket access by String Variable (occasional usage)
> > >> F) [] bracket access by Expression (infrequent usage)
> > >>
> > >> Exports can solve A. The compiler can easily detect D & E and prevent
> > >> renaming. For C, we "could" autogenerate exports for any classes with
> > >> [RemoteClass] metadata or autogenerate getter/setters.
> > >>
> > >> To me, the only difficult case is F and it will rarely happen. Maybe
> we
> > >> can detect those and warn on that.
> > >>
> > >> Of course, I could be wrong...
> > >> -Alex
> > >>
> > >>
> > >> On 1/17/20, 10:08 AM, "Josh Tynjala" <jo...@bowlerhat.dev>
> > wrote:
> > >>
> > >> Comments inline.
> > >>
> > >> On Thursday, January 16, 2020, Alex Harui <aharui@adobe.com.invalid
> >
> > >> wrote:
> > >>> Maybe we should start by agreeing on facts and then goals and then
> > >> discuss solutions.
> > >>
> > >> Yes, I think that's a good place to start.
> > >>
> > >>>
> > >>> Here are some facts that come to mind, not a complete list.
> > >>>
> > >>> 1) An export does not prevent renaming. It builds an alias. All
> > >> references within the set of sources to be minified are renamed.
> > >>
> > >> Agreed.
> > >>
> > >>> 2) Closure's export mechanism only works on non-scalars (Object,
> > >> Arrays,
> > >> Functions) and not Number, String, Boolean because non-scalars are
> > >> pass-by-reference instead of pass-by-value
> > >>
> > >> Agreed.
> > >>
> > >>> 3) The Closure Compiler is open source and designed to be extended
> > >>
> > >> Agreed.
> > >>
> > >>> 4) Use of goog.reflect.objectProperty is not necessarily the only
> > >> way to
> > >> control renaming. It is the way recommended by Google for those
> who
> > >> can't
> > >> extend the compiler. We are not constrained to modify our output
> > >> because
> > >> we have control over the compiler.
> > >>
> > >> Could you share some details how we might have more control over
> > >> Closure
> > >> compiler's renaming? It sounds like you know, at least somewhat,
> how
> > >> to use
> > >> its lower-level Java APIs, but you've never shared the details when
> > >> you've
> > >> mentioned them in this thread or in the past.
> > >>
> > >> I should add that I've personally tried to research this topic
> > myself,
> > >> but
> > >> I had a very hard time finding any information that wasn't just
> > someone
> > >> explaining to a JS developer that they needed to modify their JS
> > code.
> > >> I
> > >> eventually couldn't justify spending more time to keep looking.
> > >>
> > >>> 5) The compiler knows things about how properties were accessed.
> > >> That
> > >> information is lost in the output in many cases. Therefore, it
> > should
> > >> be
> > >> better to inform the Google minifier directly from the Royale
> > compiler,
> > >> instead of leaving hints in the output.
> > >>
> > >> Agreed. I'm personally not fully convinced that the Royale compiler
> > has
> > >> enough information for dynamic stuff (like for serialization with
> > type
> > >> Object), but that may be due to ignorance about Closure compiler's
> > >> capabilities. Even without knowing how it works, I can imagine how
> it
> > >> might
> > >> be relatively easy to prevent renaming of public variables, but the
> > >> dynamic
> > >> stuff is trickier. For the dynamic stuff, maybe it's just a matter
> of
> > >> Closure detecting when a variable is typed as Object, and then it
> can
> > >> switch to ["string"] syntax on its own (instead of us doing it in
> the
> > >> debug
> > >> build, like with -js-dynamic-access-unknown-members).
> > >>
> > >>> 7) We are pretty close to allowing renaming across modules. It was
> > >> working for a while, but a scenario popped up that isn't currently
> > >> handled. We can pre-load the Closure renamer with a name map.
> > >>
> > >> I haven't looked in detail at the module implementation and don't
> > plan
> > >> to,
> > >> but I understand it well enough at a high level to say "agreed"
> here
> > >> too
> > >>
> > >>>
> > >>> These are hypotheses, and not proven facts.
> > >>> 8) The big gain from not exporting everything is in dead code removal
> > >> instead of shorter variable names
> > >>
> > >> Agreed, personally. It seems like others have expressed interest in
> > >> both,
> > >> though. I hope that they'll be willing to prioriitze dead code
> > removal,
> > >> since it will probably have the bigger impact (my own tests
> removing
> > >> @export have been promising in this regard).
> > >>
> > >>> 9) Renaming can complicate and slow serialization/deserialization
> > >>
> > >> Agreed, and this is the harder portion to get working, I think.
> > >>
> > >> However, if release builds didn't rename public variables, and also
> > >> didn't
> > >> rename dynamic accesses, that would remove my biggest frustration
> > with
> > >> how
> > >> ActionScript works in Royale/JS compared to SWF. If both kept their
> > >> original names, things that feel broken today would "just work"
> > again.
> > >>
> > >>>
> > >>> IMO, we want to be heading in the direction of A) allowing control
> > >> over
> > >> what gets renamed
> > >>
> > >> Agreed, but as I said before, I think that dead code removal will
> > have
> > >> more
> > >> impact than control over renaming, so if it's one or the other, I'm
> > >> okay
> > >> with no control over renaming.
> > >>
> > >>> B) capturing information from the compiler,
> > >>> C) controlling the set of renames and exports directly, not through
> > >> the
> > >> output.
> > >>
> > >> Agreed, being able to pass information Closure compiler on the Java
> > >> side
> > >> would be better. than through the JS output
> > >>
> > >>
> > >>>
> > >>> My 2 cents,
> > >>> -Alex
> > >>>
> > >>>
> > >>> On 1/16/20, 2:48 PM, "Josh Tynjala" <jo...@bowlerhat.dev>
> > >> wrote:
> > >>>
> > >>> Some additional context, if anyone is interested.
> > >>>
> > >>> At the request of Harbs, I am currently investigating how we
> > >> might
> > >> remove
> > >>> @export from our generated JS code to improve the minimization
> > >> even
> > >> more.
> > >>> When I modified the compiler to skip emitting @export in some
> > >> places,
> > >> a
> > >>> release build of TourDeJewel was initially broken. When I added
> > >>> goog.reflect.objectProperty(), not only did it fix setting public
> > >> variables
> > >>> in MXML, it also made that release build of TourDeJewel start
> > >> working
> > >> again.
> > >>>
> > >>> --
> > >>> Josh Tynjala
> > >>> Bowler Hat LLC <
> > >>
> > >>
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C1e9c2c4ae9d049b2896708d79b7843c7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148813154391097&sdata=8T%2B4UIVZrakKMBkAs2qOcwalYaCVJuMxHMKPYTnbvxM%3D&reserved=0
> > >>>
> > >>>
> > >>>
> > >>> On Thu, Jan 16, 2020 at 12:59 PM Josh Tynjala <
> > >> joshtynjala@bowlerhat.dev>
> > >>> wrote:
> > >>>
> > >>>> Thank you, Harbs! Wrapping the variable name in a
> > >>>> goog.reflect.objectProperty() call works perfectly. This is
> > >> exactly
> > >> why I
> > >>>> started this thread, to see if anyone could suggest possible
> > >> alternatives.
> > >>>>
> > >>>> Thankfully, we can keep the same simple data structure as
> > >> before,
> > >> and my
> > >>>> initial proposal with functions can be forgotten. In a release
> > >> build, I can
> > >>>> see that goog.reflect.objectProperty() calls are replaced by a
> > >> simple
> > >>>> string literal (containing the minified variable name), so we
> > >> don't
> > >> have to
> > >>>> worry about extra performance impact.
> > >>>>
> > >>>> --
> > >>>> Josh Tynjala
> > >>>> Bowler Hat LLC <
> > >>
> > >>
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C1e9c2c4ae9d049b2896708d79b7843c7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148813154391097&sdata=8T%2B4UIVZrakKMBkAs2qOcwalYaCVJuMxHMKPYTnbvxM%3D&reserved=0
> > >>>
> > >>>>
> > >>>>
> > >>>> On Wed, Jan 15, 2020 at 8:32 PM Harbs <ha...@gmail.com>
> > >> wrote:
> > >>>>
> > >>>>> Sounds good!
> > >>>>>
> > >>>>>
> > >>>>>
> > >>
> > >>
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FType-Based-Property-Renaming&data=02%7C01%7Caharui%40adobe.com%7C1e9c2c4ae9d049b2896708d79b7843c7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148813154391097&sdata=IzzY7%2BhSQ9iQr9GIKd16XD%2FfGwxB50aN6J0Mzb%2BEcWA%3D&reserved=0
> > >>>>> <
> > >>>>>
> > >>
> > >>
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FType-Based-Property-Renaming&data=02%7C01%7Caharui%40adobe.com%7C1e9c2c4ae9d049b2896708d79b7843c7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148813154391097&sdata=IzzY7%2BhSQ9iQr9GIKd16XD%2FfGwxB50aN6J0Mzb%2BEcWA%3D&reserved=0
> > >>>>>>
> > >>>>>
> > >>>>> The function seems to be goog.reflect.objectProperty()
> > >>>>>
> > >>>>> I’m not sure exactly how it works though.
> > >>>>>
> > >>>>>> On Jan 16, 2020, at 1:37 AM, Greg Dove <greg.dove@gmail.com
> > >>>
> > >> wrote:
> > >>>>>>
> > >>>>>> actually just as another fyi, Harbs pointed out some
> > >> intriguing
> > >> goog
> > >>>>>> methods recently - I don't have an immediate reference to it
> > >> sorry. One
> > >>>>> of
> > >>>>>> those seemed to allow for access to renamed names by
> > >> wrapping the
> > >>>>> original
> > >>>>>> names in a 'magic' method that presumably GCC recognises
> > >> (but
> > >> presumably
> > >>>>>> returns the name unchanged in debug mode)
> > >>>>>>
> > >>>>>>
> > >>>>>> On Thu, Jan 16, 2020 at 12:33 PM Greg Dove <
> > >> greg.dove@gmail.com>
> > >> wrote:
> > >>>>>>
> > >>>>>>> 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 <
> > >>>>> joshtynjala@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%7C1e9c2c4ae9d049b2896708d79b7843c7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148813154391097&sdata=aA3JAnaQuU1GrF%2B4vmTo1Lhn38gDM4UtG2%2FdbmwBnjQ%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%7C1e9c2c4ae9d049b2896708d79b7843c7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148813154391097&sdata=8T%2B4UIVZrakKMBkAs2qOcwalYaCVJuMxHMKPYTnbvxM%3D&reserved=0
> > >>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>>
> > >>>>>
> > >>>
> > >>>
> > >>>
> > >>
> > >>
> > >>
> >
> >
>
Re: MXML and warn-public vars
Posted by Josh Tynjala <jo...@bowlerhat.dev>.
My initial implementation will probably all or nothing, in terms of
renaming, but we can revisit after to add more fine-grained control, if
necessary.
I'll try to take a look at that constant issue when I get a chance.
--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>
On Wed, Feb 5, 2020 at 12:23 PM Harbs <ha...@gmail.com> wrote:
> I hope there will be an option to prevent specific variables.
>
> The obvious ones would be ones used in MXML.
>
> Other candidates would be classes which correspond to JSON so the classes
> can be constructed with bracket notation. I’m not sure of the best way to
> declare a class for that. Maybe abusing “dynamic” classes?
>
> FWIW, I also noticed a bug recently that I didn’t log:
>
> In todomvc there’s the following in the router branch:
>
> <j:states>
> <js:State name="All"/>
> <js:State name="Active"/>
> <js:State name="Completed"/>
> </j:states>
>
> I tried using constants like so, and it failed. (At runtime the values
> were “ALL”,”ACTIVE_FILTER” and “COMPLETED_FILTER”.)
> <j:states>
> <js:State name="{TodoModel.ALL}"/>
> <js:State name="{TodoModel.ACTIVE_FILTER}"/>
> <js:State name="{TodoModel.COMPLETED_FILTER}"/>
> </j:states>
>
>
> > On Feb 5, 2020, at 9:41 PM, Josh Tynjala <jo...@bowlerhat.dev>
> wrote:
> >
> > Thank you for the tips, Alex. Much appreciated. With your help, I've
> > determined how to use Closure compiler's Java API to prevent the renaming
> > of a specific public variable that has not been @export-ed. Now, I should
> > be able to expand this prototype to a full version that prevents the
> > renaming of all public variables.
> >
> > --
> > Josh Tynjala
> > Bowler Hat LLC <https://bowlerhat.dev>
> >
> >
> > On Sun, Jan 19, 2020 at 4:58 PM Alex Harui <ah...@adobe.com.invalid>
> wrote:
> >
> >> In response to your prior post, the reason I am saying it removes
> control
> >> is because I didn't see any option to not have the compiler output
> >> goog.reflect.objectProperty and I'm not clear everyone will want/need
> it.
> >>
> >> Regarding how to control Closure Compiler's renaming, the details might
> be
> >> changing because I believe I saw that Google refactored the renamer.
> At a
> >> high-level, you probably know most of this, but for other folks reading,
> >> the Closure Compiler is a set of Java Classes that form a series of
> >> Compiler Passes. Each Pass takes information (sometimes source,
> sometimes
> >> the AST, sometimes other information, and modifies the AST. IIRC, a
> final
> >> pass generates the output. There might be more than one pass for
> output.
> >>
> >> The renaming pass we currently use can output as well as accept a file
> of
> >> rename mappings. I’m confident we can subclass or modify and replace
> the
> >> renaming pass and feed it a set of mappings. If you look in the
> >> royale-compiler source, we've already done this for some other passes.
> >> Look through the Closure compiler source for what happens to the
> compiler
> >> options:
> >>
> >> --variable_map_input_file
> >> --property_map_input_file
> >>
> >> You can build examples/mxroyale/TourDeFlexModules which outputs these
> >> files to see what is in them.
> >>
> >>
> >> We should also see if we can agree on the scenarios and likelihood of
> >> property access "by name". I can quickly think of:
> >>
> >> A) MXML setting properties by reference (high usage)
> >> B) MXML setting properties by value (high usage)
> >> C) Serializers/Deserializers (moderate usage)
> >> D) [] bracket access by Literal (occasional usage)
> >> E) [] bracket access by String Variable (occasional usage)
> >> F) [] bracket access by Expression (infrequent usage)
> >>
> >> Exports can solve A. The compiler can easily detect D & E and prevent
> >> renaming. For C, we "could" autogenerate exports for any classes with
> >> [RemoteClass] metadata or autogenerate getter/setters.
> >>
> >> To me, the only difficult case is F and it will rarely happen. Maybe we
> >> can detect those and warn on that.
> >>
> >> Of course, I could be wrong...
> >> -Alex
> >>
> >>
> >> On 1/17/20, 10:08 AM, "Josh Tynjala" <jo...@bowlerhat.dev>
> wrote:
> >>
> >> Comments inline.
> >>
> >> On Thursday, January 16, 2020, Alex Harui <ah...@adobe.com.invalid>
> >> wrote:
> >>> Maybe we should start by agreeing on facts and then goals and then
> >> discuss solutions.
> >>
> >> Yes, I think that's a good place to start.
> >>
> >>>
> >>> Here are some facts that come to mind, not a complete list.
> >>>
> >>> 1) An export does not prevent renaming. It builds an alias. All
> >> references within the set of sources to be minified are renamed.
> >>
> >> Agreed.
> >>
> >>> 2) Closure's export mechanism only works on non-scalars (Object,
> >> Arrays,
> >> Functions) and not Number, String, Boolean because non-scalars are
> >> pass-by-reference instead of pass-by-value
> >>
> >> Agreed.
> >>
> >>> 3) The Closure Compiler is open source and designed to be extended
> >>
> >> Agreed.
> >>
> >>> 4) Use of goog.reflect.objectProperty is not necessarily the only
> >> way to
> >> control renaming. It is the way recommended by Google for those who
> >> can't
> >> extend the compiler. We are not constrained to modify our output
> >> because
> >> we have control over the compiler.
> >>
> >> Could you share some details how we might have more control over
> >> Closure
> >> compiler's renaming? It sounds like you know, at least somewhat, how
> >> to use
> >> its lower-level Java APIs, but you've never shared the details when
> >> you've
> >> mentioned them in this thread or in the past.
> >>
> >> I should add that I've personally tried to research this topic
> myself,
> >> but
> >> I had a very hard time finding any information that wasn't just
> someone
> >> explaining to a JS developer that they needed to modify their JS
> code.
> >> I
> >> eventually couldn't justify spending more time to keep looking.
> >>
> >>> 5) The compiler knows things about how properties were accessed.
> >> That
> >> information is lost in the output in many cases. Therefore, it
> should
> >> be
> >> better to inform the Google minifier directly from the Royale
> compiler,
> >> instead of leaving hints in the output.
> >>
> >> Agreed. I'm personally not fully convinced that the Royale compiler
> has
> >> enough information for dynamic stuff (like for serialization with
> type
> >> Object), but that may be due to ignorance about Closure compiler's
> >> capabilities. Even without knowing how it works, I can imagine how it
> >> might
> >> be relatively easy to prevent renaming of public variables, but the
> >> dynamic
> >> stuff is trickier. For the dynamic stuff, maybe it's just a matter of
> >> Closure detecting when a variable is typed as Object, and then it can
> >> switch to ["string"] syntax on its own (instead of us doing it in the
> >> debug
> >> build, like with -js-dynamic-access-unknown-members).
> >>
> >>> 7) We are pretty close to allowing renaming across modules. It was
> >> working for a while, but a scenario popped up that isn't currently
> >> handled. We can pre-load the Closure renamer with a name map.
> >>
> >> I haven't looked in detail at the module implementation and don't
> plan
> >> to,
> >> but I understand it well enough at a high level to say "agreed" here
> >> too
> >>
> >>>
> >>> These are hypotheses, and not proven facts.
> >>> 8) The big gain from not exporting everything is in dead code removal
> >> instead of shorter variable names
> >>
> >> Agreed, personally. It seems like others have expressed interest in
> >> both,
> >> though. I hope that they'll be willing to prioriitze dead code
> removal,
> >> since it will probably have the bigger impact (my own tests removing
> >> @export have been promising in this regard).
> >>
> >>> 9) Renaming can complicate and slow serialization/deserialization
> >>
> >> Agreed, and this is the harder portion to get working, I think.
> >>
> >> However, if release builds didn't rename public variables, and also
> >> didn't
> >> rename dynamic accesses, that would remove my biggest frustration
> with
> >> how
> >> ActionScript works in Royale/JS compared to SWF. If both kept their
> >> original names, things that feel broken today would "just work"
> again.
> >>
> >>>
> >>> IMO, we want to be heading in the direction of A) allowing control
> >> over
> >> what gets renamed
> >>
> >> Agreed, but as I said before, I think that dead code removal will
> have
> >> more
> >> impact than control over renaming, so if it's one or the other, I'm
> >> okay
> >> with no control over renaming.
> >>
> >>> B) capturing information from the compiler,
> >>> C) controlling the set of renames and exports directly, not through
> >> the
> >> output.
> >>
> >> Agreed, being able to pass information Closure compiler on the Java
> >> side
> >> would be better. than through the JS output
> >>
> >>
> >>>
> >>> My 2 cents,
> >>> -Alex
> >>>
> >>>
> >>> On 1/16/20, 2:48 PM, "Josh Tynjala" <jo...@bowlerhat.dev>
> >> wrote:
> >>>
> >>> Some additional context, if anyone is interested.
> >>>
> >>> At the request of Harbs, I am currently investigating how we
> >> might
> >> remove
> >>> @export from our generated JS code to improve the minimization
> >> even
> >> more.
> >>> When I modified the compiler to skip emitting @export in some
> >> places,
> >> a
> >>> release build of TourDeJewel was initially broken. When I added
> >>> goog.reflect.objectProperty(), not only did it fix setting public
> >> variables
> >>> in MXML, it also made that release build of TourDeJewel start
> >> working
> >> again.
> >>>
> >>> --
> >>> Josh Tynjala
> >>> Bowler Hat LLC <
> >>
> >>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C1e9c2c4ae9d049b2896708d79b7843c7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148813154391097&sdata=8T%2B4UIVZrakKMBkAs2qOcwalYaCVJuMxHMKPYTnbvxM%3D&reserved=0
> >>>
> >>>
> >>>
> >>> On Thu, Jan 16, 2020 at 12:59 PM Josh Tynjala <
> >> joshtynjala@bowlerhat.dev>
> >>> wrote:
> >>>
> >>>> Thank you, Harbs! Wrapping the variable name in a
> >>>> goog.reflect.objectProperty() call works perfectly. This is
> >> exactly
> >> why I
> >>>> started this thread, to see if anyone could suggest possible
> >> alternatives.
> >>>>
> >>>> Thankfully, we can keep the same simple data structure as
> >> before,
> >> and my
> >>>> initial proposal with functions can be forgotten. In a release
> >> build, I can
> >>>> see that goog.reflect.objectProperty() calls are replaced by a
> >> simple
> >>>> string literal (containing the minified variable name), so we
> >> don't
> >> have to
> >>>> worry about extra performance impact.
> >>>>
> >>>> --
> >>>> Josh Tynjala
> >>>> Bowler Hat LLC <
> >>
> >>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C1e9c2c4ae9d049b2896708d79b7843c7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148813154391097&sdata=8T%2B4UIVZrakKMBkAs2qOcwalYaCVJuMxHMKPYTnbvxM%3D&reserved=0
> >>>
> >>>>
> >>>>
> >>>> On Wed, Jan 15, 2020 at 8:32 PM Harbs <ha...@gmail.com>
> >> wrote:
> >>>>
> >>>>> Sounds good!
> >>>>>
> >>>>>
> >>>>>
> >>
> >>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FType-Based-Property-Renaming&data=02%7C01%7Caharui%40adobe.com%7C1e9c2c4ae9d049b2896708d79b7843c7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148813154391097&sdata=IzzY7%2BhSQ9iQr9GIKd16XD%2FfGwxB50aN6J0Mzb%2BEcWA%3D&reserved=0
> >>>>> <
> >>>>>
> >>
> >>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FType-Based-Property-Renaming&data=02%7C01%7Caharui%40adobe.com%7C1e9c2c4ae9d049b2896708d79b7843c7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148813154391097&sdata=IzzY7%2BhSQ9iQr9GIKd16XD%2FfGwxB50aN6J0Mzb%2BEcWA%3D&reserved=0
> >>>>>>
> >>>>>
> >>>>> The function seems to be goog.reflect.objectProperty()
> >>>>>
> >>>>> I’m not sure exactly how it works though.
> >>>>>
> >>>>>> On Jan 16, 2020, at 1:37 AM, Greg Dove <greg.dove@gmail.com
> >>>
> >> wrote:
> >>>>>>
> >>>>>> actually just as another fyi, Harbs pointed out some
> >> intriguing
> >> goog
> >>>>>> methods recently - I don't have an immediate reference to it
> >> sorry. One
> >>>>> of
> >>>>>> those seemed to allow for access to renamed names by
> >> wrapping the
> >>>>> original
> >>>>>> names in a 'magic' method that presumably GCC recognises
> >> (but
> >> presumably
> >>>>>> returns the name unchanged in debug mode)
> >>>>>>
> >>>>>>
> >>>>>> On Thu, Jan 16, 2020 at 12:33 PM Greg Dove <
> >> greg.dove@gmail.com>
> >> wrote:
> >>>>>>
> >>>>>>> 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 <
> >>>>> joshtynjala@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%7C1e9c2c4ae9d049b2896708d79b7843c7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148813154391097&sdata=aA3JAnaQuU1GrF%2B4vmTo1Lhn38gDM4UtG2%2FdbmwBnjQ%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%7C1e9c2c4ae9d049b2896708d79b7843c7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148813154391097&sdata=8T%2B4UIVZrakKMBkAs2qOcwalYaCVJuMxHMKPYTnbvxM%3D&reserved=0
> >>>
> >>>>>>>>
> >>>>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >>>
> >>
> >>
> >>
>
>
Re: MXML and warn-public vars
Posted by Harbs <ha...@gmail.com>.
I hope there will be an option to prevent specific variables.
The obvious ones would be ones used in MXML.
Other candidates would be classes which correspond to JSON so the classes can be constructed with bracket notation. I’m not sure of the best way to declare a class for that. Maybe abusing “dynamic” classes?
FWIW, I also noticed a bug recently that I didn’t log:
In todomvc there’s the following in the router branch:
<j:states>
<js:State name="All"/>
<js:State name="Active"/>
<js:State name="Completed"/>
</j:states>
I tried using constants like so, and it failed. (At runtime the values were “ALL”,”ACTIVE_FILTER” and “COMPLETED_FILTER”.)
<j:states>
<js:State name="{TodoModel.ALL}"/>
<js:State name="{TodoModel.ACTIVE_FILTER}"/>
<js:State name="{TodoModel.COMPLETED_FILTER}"/>
</j:states>
> On Feb 5, 2020, at 9:41 PM, Josh Tynjala <jo...@bowlerhat.dev> wrote:
>
> Thank you for the tips, Alex. Much appreciated. With your help, I've
> determined how to use Closure compiler's Java API to prevent the renaming
> of a specific public variable that has not been @export-ed. Now, I should
> be able to expand this prototype to a full version that prevents the
> renaming of all public variables.
>
> --
> Josh Tynjala
> Bowler Hat LLC <https://bowlerhat.dev>
>
>
> On Sun, Jan 19, 2020 at 4:58 PM Alex Harui <ah...@adobe.com.invalid> wrote:
>
>> In response to your prior post, the reason I am saying it removes control
>> is because I didn't see any option to not have the compiler output
>> goog.reflect.objectProperty and I'm not clear everyone will want/need it.
>>
>> Regarding how to control Closure Compiler's renaming, the details might be
>> changing because I believe I saw that Google refactored the renamer. At a
>> high-level, you probably know most of this, but for other folks reading,
>> the Closure Compiler is a set of Java Classes that form a series of
>> Compiler Passes. Each Pass takes information (sometimes source, sometimes
>> the AST, sometimes other information, and modifies the AST. IIRC, a final
>> pass generates the output. There might be more than one pass for output.
>>
>> The renaming pass we currently use can output as well as accept a file of
>> rename mappings. I’m confident we can subclass or modify and replace the
>> renaming pass and feed it a set of mappings. If you look in the
>> royale-compiler source, we've already done this for some other passes.
>> Look through the Closure compiler source for what happens to the compiler
>> options:
>>
>> --variable_map_input_file
>> --property_map_input_file
>>
>> You can build examples/mxroyale/TourDeFlexModules which outputs these
>> files to see what is in them.
>>
>>
>> We should also see if we can agree on the scenarios and likelihood of
>> property access "by name". I can quickly think of:
>>
>> A) MXML setting properties by reference (high usage)
>> B) MXML setting properties by value (high usage)
>> C) Serializers/Deserializers (moderate usage)
>> D) [] bracket access by Literal (occasional usage)
>> E) [] bracket access by String Variable (occasional usage)
>> F) [] bracket access by Expression (infrequent usage)
>>
>> Exports can solve A. The compiler can easily detect D & E and prevent
>> renaming. For C, we "could" autogenerate exports for any classes with
>> [RemoteClass] metadata or autogenerate getter/setters.
>>
>> To me, the only difficult case is F and it will rarely happen. Maybe we
>> can detect those and warn on that.
>>
>> Of course, I could be wrong...
>> -Alex
>>
>>
>> On 1/17/20, 10:08 AM, "Josh Tynjala" <jo...@bowlerhat.dev> wrote:
>>
>> Comments inline.
>>
>> On Thursday, January 16, 2020, Alex Harui <ah...@adobe.com.invalid>
>> wrote:
>>> Maybe we should start by agreeing on facts and then goals and then
>> discuss solutions.
>>
>> Yes, I think that's a good place to start.
>>
>>>
>>> Here are some facts that come to mind, not a complete list.
>>>
>>> 1) An export does not prevent renaming. It builds an alias. All
>> references within the set of sources to be minified are renamed.
>>
>> Agreed.
>>
>>> 2) Closure's export mechanism only works on non-scalars (Object,
>> Arrays,
>> Functions) and not Number, String, Boolean because non-scalars are
>> pass-by-reference instead of pass-by-value
>>
>> Agreed.
>>
>>> 3) The Closure Compiler is open source and designed to be extended
>>
>> Agreed.
>>
>>> 4) Use of goog.reflect.objectProperty is not necessarily the only
>> way to
>> control renaming. It is the way recommended by Google for those who
>> can't
>> extend the compiler. We are not constrained to modify our output
>> because
>> we have control over the compiler.
>>
>> Could you share some details how we might have more control over
>> Closure
>> compiler's renaming? It sounds like you know, at least somewhat, how
>> to use
>> its lower-level Java APIs, but you've never shared the details when
>> you've
>> mentioned them in this thread or in the past.
>>
>> I should add that I've personally tried to research this topic myself,
>> but
>> I had a very hard time finding any information that wasn't just someone
>> explaining to a JS developer that they needed to modify their JS code.
>> I
>> eventually couldn't justify spending more time to keep looking.
>>
>>> 5) The compiler knows things about how properties were accessed.
>> That
>> information is lost in the output in many cases. Therefore, it should
>> be
>> better to inform the Google minifier directly from the Royale compiler,
>> instead of leaving hints in the output.
>>
>> Agreed. I'm personally not fully convinced that the Royale compiler has
>> enough information for dynamic stuff (like for serialization with type
>> Object), but that may be due to ignorance about Closure compiler's
>> capabilities. Even without knowing how it works, I can imagine how it
>> might
>> be relatively easy to prevent renaming of public variables, but the
>> dynamic
>> stuff is trickier. For the dynamic stuff, maybe it's just a matter of
>> Closure detecting when a variable is typed as Object, and then it can
>> switch to ["string"] syntax on its own (instead of us doing it in the
>> debug
>> build, like with -js-dynamic-access-unknown-members).
>>
>>> 7) We are pretty close to allowing renaming across modules. It was
>> working for a while, but a scenario popped up that isn't currently
>> handled. We can pre-load the Closure renamer with a name map.
>>
>> I haven't looked in detail at the module implementation and don't plan
>> to,
>> but I understand it well enough at a high level to say "agreed" here
>> too
>>
>>>
>>> These are hypotheses, and not proven facts.
>>> 8) The big gain from not exporting everything is in dead code removal
>> instead of shorter variable names
>>
>> Agreed, personally. It seems like others have expressed interest in
>> both,
>> though. I hope that they'll be willing to prioriitze dead code removal,
>> since it will probably have the bigger impact (my own tests removing
>> @export have been promising in this regard).
>>
>>> 9) Renaming can complicate and slow serialization/deserialization
>>
>> Agreed, and this is the harder portion to get working, I think.
>>
>> However, if release builds didn't rename public variables, and also
>> didn't
>> rename dynamic accesses, that would remove my biggest frustration with
>> how
>> ActionScript works in Royale/JS compared to SWF. If both kept their
>> original names, things that feel broken today would "just work" again.
>>
>>>
>>> IMO, we want to be heading in the direction of A) allowing control
>> over
>> what gets renamed
>>
>> Agreed, but as I said before, I think that dead code removal will have
>> more
>> impact than control over renaming, so if it's one or the other, I'm
>> okay
>> with no control over renaming.
>>
>>> B) capturing information from the compiler,
>>> C) controlling the set of renames and exports directly, not through
>> the
>> output.
>>
>> Agreed, being able to pass information Closure compiler on the Java
>> side
>> would be better. than through the JS output
>>
>>
>>>
>>> My 2 cents,
>>> -Alex
>>>
>>>
>>> On 1/16/20, 2:48 PM, "Josh Tynjala" <jo...@bowlerhat.dev>
>> wrote:
>>>
>>> Some additional context, if anyone is interested.
>>>
>>> At the request of Harbs, I am currently investigating how we
>> might
>> remove
>>> @export from our generated JS code to improve the minimization
>> even
>> more.
>>> When I modified the compiler to skip emitting @export in some
>> places,
>> a
>>> release build of TourDeJewel was initially broken. When I added
>>> goog.reflect.objectProperty(), not only did it fix setting public
>> variables
>>> in MXML, it also made that release build of TourDeJewel start
>> working
>> again.
>>>
>>> --
>>> Josh Tynjala
>>> Bowler Hat LLC <
>>
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C1e9c2c4ae9d049b2896708d79b7843c7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148813154391097&sdata=8T%2B4UIVZrakKMBkAs2qOcwalYaCVJuMxHMKPYTnbvxM%3D&reserved=0
>>>
>>>
>>>
>>> On Thu, Jan 16, 2020 at 12:59 PM Josh Tynjala <
>> joshtynjala@bowlerhat.dev>
>>> wrote:
>>>
>>>> Thank you, Harbs! Wrapping the variable name in a
>>>> goog.reflect.objectProperty() call works perfectly. This is
>> exactly
>> why I
>>>> started this thread, to see if anyone could suggest possible
>> alternatives.
>>>>
>>>> Thankfully, we can keep the same simple data structure as
>> before,
>> and my
>>>> initial proposal with functions can be forgotten. In a release
>> build, I can
>>>> see that goog.reflect.objectProperty() calls are replaced by a
>> simple
>>>> string literal (containing the minified variable name), so we
>> don't
>> have to
>>>> worry about extra performance impact.
>>>>
>>>> --
>>>> Josh Tynjala
>>>> Bowler Hat LLC <
>>
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C1e9c2c4ae9d049b2896708d79b7843c7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148813154391097&sdata=8T%2B4UIVZrakKMBkAs2qOcwalYaCVJuMxHMKPYTnbvxM%3D&reserved=0
>>>
>>>>
>>>>
>>>> On Wed, Jan 15, 2020 at 8:32 PM Harbs <ha...@gmail.com>
>> wrote:
>>>>
>>>>> Sounds good!
>>>>>
>>>>>
>>>>>
>>
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FType-Based-Property-Renaming&data=02%7C01%7Caharui%40adobe.com%7C1e9c2c4ae9d049b2896708d79b7843c7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148813154391097&sdata=IzzY7%2BhSQ9iQr9GIKd16XD%2FfGwxB50aN6J0Mzb%2BEcWA%3D&reserved=0
>>>>> <
>>>>>
>>
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FType-Based-Property-Renaming&data=02%7C01%7Caharui%40adobe.com%7C1e9c2c4ae9d049b2896708d79b7843c7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148813154391097&sdata=IzzY7%2BhSQ9iQr9GIKd16XD%2FfGwxB50aN6J0Mzb%2BEcWA%3D&reserved=0
>>>>>>
>>>>>
>>>>> The function seems to be goog.reflect.objectProperty()
>>>>>
>>>>> I’m not sure exactly how it works though.
>>>>>
>>>>>> On Jan 16, 2020, at 1:37 AM, Greg Dove <greg.dove@gmail.com
>>>
>> wrote:
>>>>>>
>>>>>> actually just as another fyi, Harbs pointed out some
>> intriguing
>> goog
>>>>>> methods recently - I don't have an immediate reference to it
>> sorry. One
>>>>> of
>>>>>> those seemed to allow for access to renamed names by
>> wrapping the
>>>>> original
>>>>>> names in a 'magic' method that presumably GCC recognises
>> (but
>> presumably
>>>>>> returns the name unchanged in debug mode)
>>>>>>
>>>>>>
>>>>>> On Thu, Jan 16, 2020 at 12:33 PM Greg Dove <
>> greg.dove@gmail.com>
>> wrote:
>>>>>>
>>>>>>> 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 <
>>>>> joshtynjala@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%7C1e9c2c4ae9d049b2896708d79b7843c7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148813154391097&sdata=aA3JAnaQuU1GrF%2B4vmTo1Lhn38gDM4UtG2%2FdbmwBnjQ%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%7C1e9c2c4ae9d049b2896708d79b7843c7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148813154391097&sdata=8T%2B4UIVZrakKMBkAs2qOcwalYaCVJuMxHMKPYTnbvxM%3D&reserved=0
>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>
>>
>>
Re: MXML and warn-public vars
Posted by Alex Harui <ah...@adobe.com.INVALID>.
@joshtynjala@apache.org I had trouble wrapping my head around the polarity of this option as well. Public getter/setters and methods are always being renamed, it is when you don't rename public vars that we try to muck with that renaming.
I saw your attempt to fix this morning. I agree with the concern you put in a comment. If the module relied on bracket access like this["UP"] the module will now be broken because the modules use of UP will be renamed. That's why I'm thinking that it might be best to have a list of reserved names instead.
Thoughts?
-Alex
On 2/20/20, 7:19 AM, "Josh Tynjala" <jo...@bowlerhat.dev> wrote:
Sorry, yes, of course it's false. Haven't had my morning tea yet.
--
Josh Tynjala
Bowler Hat LLC <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7Cdaafeb6ce92c4ae9f29b08d7b618550d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178087942332811&sdata=Rfy8aVTEIVu0m%2Be2YNVLtREF9k5Iodpbb7e%2F1hmma%2BU%3D&reserved=0>
On Thu, Feb 20, 2020 at 7:17 AM Josh Tynjala <jo...@bowlerhat.dev>
wrote:
> Do you mean -rename-public-vars=true instead of false? False should
> preserve the original behavior.
>
> --
> Josh Tynjala
> Bowler Hat LLC <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7Cdaafeb6ce92c4ae9f29b08d7b618550d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178087942332811&sdata=Rfy8aVTEIVu0m%2Be2YNVLtREF9k5Iodpbb7e%2F1hmma%2BU%3D&reserved=0>
>
>
> On Thu, Feb 20, 2020 at 1:44 AM Alex Harui <ah...@adobe.com.invalid>
> wrote:
>
>> This change is breaking some modules when -rename-public-vars=false.
>> Let's say the main app has some method "foo" that gets renamed. It might
>> accidentally get a minified name that coincides with a public var in the
>> module. For tour de flex, some API gets the minified name "UP". A module
>> has code that references Keyboard.UP.
>>
>> In Pashmina's app, some API gets a minified name like "vs" and the module
>> has a property "vs" (for a ViewStack).
>>
>> We try to allow renaming of APIs in modules for size savings. The list
>> of renames in the main app is output to a file and read into the compiler
>> when compiling the module so it starts with the same renaming map.
>>
>> One thought I had about solving this is to add another compiler option
>> that allows a list of other names to not rename. So for the "UP" scenario,
>> I would compile the main app with, say, -forbidden-minified-names=UP.
>> Folks can probably work around the problem by using Keyboard.UP in the
>> main app, but that bloats the main app. The compiler can already read a
>> file of rename maps, so we could just use that, but I think a simpler
>> command-line list will be more convenient.
>>
>> Thoughts?
>> -Alex
>>
>> On 2/5/20, 12:18 PM, "Josh Tynjala" <jo...@bowlerhat.dev> wrote:
>>
>> Yeah, I'll make sure that users can control whether renaming happens
>> or not.
>>
>> --
>> Josh Tynjala
>> Bowler Hat LLC <
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7Cdaafeb6ce92c4ae9f29b08d7b618550d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178087942332811&sdata=Rfy8aVTEIVu0m%2Be2YNVLtREF9k5Iodpbb7e%2F1hmma%2BU%3D&reserved=0
>> >
>>
>>
>> On Wed, Feb 5, 2020 at 11:51 AM Alex Harui <ah...@adobe.com.invalid>
>> wrote:
>>
>> > Great work, Josh!
>> >
>> > I have to say that the objectProperty output was adding pain to
>> debugging
>> > so looking forward to that going away. I'm assuming there will be
>> compiler
>> > options/directives to control renaming? I think there are some
>> scenarios
>> > where it is safe to have public variables renamed.
>> >
>> > Thanks,
>> > -Alex
>> >
>> > On 2/5/20, 11:44 AM, "Josh Tynjala" <jo...@bowlerhat.dev>
>> wrote:
>> >
>> > Thank you for the tips, Alex. Much appreciated. With your help,
>> I've
>> > determined how to use Closure compiler's Java API to prevent the
>> > renaming
>> > of a specific public variable that has not been @export-ed.
>> Now, I
>> > should
>> > be able to expand this prototype to a full version that
>> prevents the
>> > renaming of all public variables.
>> >
>> > --
>> > Josh Tynjala
>> > Bowler Hat LLC <
>> >
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7Cdaafeb6ce92c4ae9f29b08d7b618550d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178087942342803&sdata=9zorxM8uBxGzorkscbCQSjKBKvtUuhAMVXTw6O5BV4E%3D&reserved=0
>> > >
>> >
>> >
>> > On Sun, Jan 19, 2020 at 4:58 PM Alex Harui
>> <ah...@adobe.com.invalid>
>> > wrote:
>> >
>> > > In response to your prior post, the reason I am saying it
>> removes
>> > control
>> > > is because I didn't see any option to not have the compiler
>> output
>> > > goog.reflect.objectProperty and I'm not clear everyone will
>> > want/need it.
>> > >
>> > > Regarding how to control Closure Compiler's renaming, the
>> details
>> > might be
>> > > changing because I believe I saw that Google refactored the
>> > renamer. At a
>> > > high-level, you probably know most of this, but for other
>> folks
>> > reading,
>> > > the Closure Compiler is a set of Java Classes that form a
>> series of
>> > > Compiler Passes. Each Pass takes information (sometimes
>> source,
>> > sometimes
>> > > the AST, sometimes other information, and modifies the AST.
>> IIRC, a
>> > final
>> > > pass generates the output. There might be more than one pass
>> for
>> > output.
>> > >
>> > > The renaming pass we currently use can output as well as
>> accept a
>> > file of
>> > > rename mappings. I’m confident we can subclass or modify and
>> > replace the
>> > > renaming pass and feed it a set of mappings. If you look in
>> the
>> > > royale-compiler source, we've already done this for some other
>> > passes.
>> > > Look through the Closure compiler source for what happens to
>> the
>> > compiler
>> > > options:
>> > >
>> > > --variable_map_input_file
>> > > --property_map_input_file
>> > >
>> > > You can build examples/mxroyale/TourDeFlexModules which
>> outputs these
>> > > files to see what is in them.
>> > >
>> > >
>> > > We should also see if we can agree on the scenarios and
>> likelihood of
>> > > property access "by name". I can quickly think of:
>> > >
>> > > A) MXML setting properties by reference (high usage)
>> > > B) MXML setting properties by value (high usage)
>> > > C) Serializers/Deserializers (moderate usage)
>> > > D) [] bracket access by Literal (occasional usage)
>> > > E) [] bracket access by String Variable (occasional usage)
>> > > F) [] bracket access by Expression (infrequent usage)
>> > >
>> > > Exports can solve A. The compiler can easily detect D & E and
>> > prevent
>> > > renaming. For C, we "could" autogenerate exports for any
>> classes
>> > with
>> > > [RemoteClass] metadata or autogenerate getter/setters.
>> > >
>> > > To me, the only difficult case is F and it will rarely happen.
>> > Maybe we
>> > > can detect those and warn on that.
>> > >
>> > > Of course, I could be wrong...
>> > > -Alex
>> > >
>> > >
>> > > On 1/17/20, 10:08 AM, "Josh Tynjala" <
>> joshtynjala@bowlerhat.dev>
>> > wrote:
>> > >
>> > > Comments inline.
>> > >
>> > > On Thursday, January 16, 2020, Alex Harui
>> > <ah...@adobe.com.invalid>
>> > > wrote:
>> > > > Maybe we should start by agreeing on facts and then
>> goals and
>> > then
>> > > discuss solutions.
>> > >
>> > > Yes, I think that's a good place to start.
>> > >
>> > > >
>> > > > Here are some facts that come to mind, not a complete
>> list.
>> > > >
>> > > > 1) An export does not prevent renaming. It builds an
>> alias.
>> > All
>> > > references within the set of sources to be minified are
>> renamed.
>> > >
>> > > Agreed.
>> > >
>> > > > 2) Closure's export mechanism only works on non-scalars
>> > (Object,
>> > > Arrays,
>> > > Functions) and not Number, String, Boolean because
>> non-scalars
>> > are
>> > > pass-by-reference instead of pass-by-value
>> > >
>> > > Agreed.
>> > >
>> > > > 3) The Closure Compiler is open source and designed to
>> be
>> > extended
>> > >
>> > > Agreed.
>> > >
>> > > > 4) Use of goog.reflect.objectProperty is not
>> necessarily the
>> > only
>> > > way to
>> > > control renaming. It is the way recommended by Google
>> for those
>> > who
>> > > can't
>> > > extend the compiler. We are not constrained to modify
>> our output
>> > > because
>> > > we have control over the compiler.
>> > >
>> > > Could you share some details how we might have more
>> control over
>> > > Closure
>> > > compiler's renaming? It sounds like you know, at least
>> somewhat,
>> > how
>> > > to use
>> > > its lower-level Java APIs, but you've never shared the
>> details
>> > when
>> > > you've
>> > > mentioned them in this thread or in the past.
>> > >
>> > > I should add that I've personally tried to research this
>> topic
>> > myself,
>> > > but
>> > > I had a very hard time finding any information that
>> wasn't just
>> > someone
>> > > explaining to a JS developer that they needed to modify
>> their JS
>> > code.
>> > > I
>> > > eventually couldn't justify spending more time to keep
>> looking.
>> > >
>> > > > 5) The compiler knows things about how properties were
>> > accessed.
>> > > That
>> > > information is lost in the output in many cases.
>> Therefore, it
>> > should
>> > > be
>> > > better to inform the Google minifier directly from the
>> Royale
>> > compiler,
>> > > instead of leaving hints in the output.
>> > >
>> > > Agreed. I'm personally not fully convinced that the Royale
>> > compiler has
>> > > enough information for dynamic stuff (like for
>> serialization
>> > with type
>> > > Object), but that may be due to ignorance about Closure
>> > compiler's
>> > > capabilities. Even without knowing how it works, I can
>> imagine
>> > how it
>> > > might
>> > > be relatively easy to prevent renaming of public
>> variables, but
>> > the
>> > > dynamic
>> > > stuff is trickier. For the dynamic stuff, maybe it's just
>> a
>> > matter of
>> > > Closure detecting when a variable is typed as Object, and
>> then
>> > it can
>> > > switch to ["string"] syntax on its own (instead of us
>> doing it
>> > in the
>> > > debug
>> > > build, like with -js-dynamic-access-unknown-members).
>> > >
>> > > > 7) We are pretty close to allowing renaming across
>> modules.
>> > It was
>> > > working for a while, but a scenario popped up that isn't
>> > currently
>> > > handled. We can pre-load the Closure renamer with a name
>> map.
>> > >
>> > > I haven't looked in detail at the module implementation
>> and
>> > don't plan
>> > > to,
>> > > but I understand it well enough at a high level to say
>> "agreed"
>> > here
>> > > too
>> > >
>> > > >
>> > > > These are hypotheses, and not proven facts.
>> > > > 8) The big gain from not exporting everything is in
>> dead code
>> > removal
>> > > instead of shorter variable names
>> > >
>> > > Agreed, personally. It seems like others have expressed
>> interest
>> > in
>> > > both,
>> > > though. I hope that they'll be willing to prioriitze dead
>> code
>> > removal,
>> > > since it will probably have the bigger impact (my own
>> tests
>> > removing
>> > > @export have been promising in this regard).
>> > >
>> > > > 9) Renaming can complicate and slow
>> > serialization/deserialization
>> > >
>> > > Agreed, and this is the harder portion to get working, I
>> think.
>> > >
>> > > However, if release builds didn't rename public
>> variables, and
>> > also
>> > > didn't
>> > > rename dynamic accesses, that would remove my biggest
>> > frustration with
>> > > how
>> > > ActionScript works in Royale/JS compared to SWF. If both
>> kept
>> > their
>> > > original names, things that feel broken today would "just
>> work"
>> > again.
>> > >
>> > > >
>> > > > IMO, we want to be heading in the direction of A)
>> allowing
>> > control
>> > > over
>> > > what gets renamed
>> > >
>> > > Agreed, but as I said before, I think that dead code
>> removal
>> > will have
>> > > more
>> > > impact than control over renaming, so if it's one or the
>> other,
>> > I'm
>> > > okay
>> > > with no control over renaming.
>> > >
>> > > > B) capturing information from the compiler,
>> > > > C) controlling the set of renames and exports directly,
>> not
>> > through
>> > > the
>> > > output.
>> > >
>> > > Agreed, being able to pass information Closure compiler
>> on the
>> > Java
>> > > side
>> > > would be better. than through the JS output
>> > >
>> > >
>> > > >
>> > > > My 2 cents,
>> > > > -Alex
>> > > >
>> > > >
>> > > > On 1/16/20, 2:48 PM, "Josh Tynjala" <
>> joshtynjala@bowlerhat.dev
>> > >
>> > > wrote:
>> > > >
>> > > > Some additional context, if anyone is interested.
>> > > >
>> > > > At the request of Harbs, I am currently
>> investigating how
>> > we
>> > > might
>> > > remove
>> > > > @export from our generated JS code to improve the
>> > minimization
>> > > even
>> > > more.
>> > > > When I modified the compiler to skip emitting
>> @export in
>> > some
>> > > places,
>> > > a
>> > > > release build of TourDeJewel was initially broken.
>> When I
>> > added
>> > > > goog.reflect.objectProperty(), not only did it fix
>> setting
>> > public
>> > > variables
>> > > > in MXML, it also made that release build of
>> TourDeJewel
>> > start
>> > > working
>> > > again.
>> > > >
>> > > > --
>> > > > Josh Tynjala
>> > > > Bowler Hat LLC <
>> > >
>> > >
>> >
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7Cdaafeb6ce92c4ae9f29b08d7b618550d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178087942342803&sdata=9zorxM8uBxGzorkscbCQSjKBKvtUuhAMVXTw6O5BV4E%3D&reserved=0
>> > > >
>> > > >
>> > > >
>> > > > On Thu, Jan 16, 2020 at 12:59 PM Josh Tynjala <
>> > > joshtynjala@bowlerhat.dev>
>> > > > wrote:
>> > > >
>> > > > > Thank you, Harbs! Wrapping the variable name in a
>> > > > > goog.reflect.objectProperty() call works
>> perfectly. This
>> > is
>> > > exactly
>> > > why I
>> > > > > started this thread, to see if anyone could
>> suggest
>> > possible
>> > > alternatives.
>> > > > >
>> > > > > Thankfully, we can keep the same simple data
>> structure as
>> > > before,
>> > > and my
>> > > > > initial proposal with functions can be forgotten.
>> In a
>> > release
>> > > build, I can
>> > > > > see that goog.reflect.objectProperty() calls are
>> > replaced by a
>> > > simple
>> > > > > string literal (containing the minified variable
>> name),
>> > so we
>> > > don't
>> > > have to
>> > > > > worry about extra performance impact.
>> > > > >
>> > > > > --
>> > > > > Josh Tynjala
>> > > > > Bowler Hat LLC <
>> > >
>> > >
>> >
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7Cdaafeb6ce92c4ae9f29b08d7b618550d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178087942342803&sdata=9zorxM8uBxGzorkscbCQSjKBKvtUuhAMVXTw6O5BV4E%3D&reserved=0
>> > > >
>> > > > >
>> > > > >
>> > > > > On Wed, Jan 15, 2020 at 8:32 PM Harbs <
>> > harbs.lists@gmail.com>
>> > > wrote:
>> > > > >
>> > > > >> Sounds good!
>> > > > >>
>> > > > >>
>> > > > >>
>> > >
>> > >
>> >
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FType-Based-Property-Renaming&data=02%7C01%7Caharui%40adobe.com%7Cdaafeb6ce92c4ae9f29b08d7b618550d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178087942342803&sdata=8tXO0wt5QDXn7BYtVrR4oTvcHfzZor2pMe5%2FGlA%2FLhk%3D&reserved=0
>> > > > >> <
>> > > > >>
>> > >
>> > >
>> >
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FType-Based-Property-Renaming&data=02%7C01%7Caharui%40adobe.com%7Cdaafeb6ce92c4ae9f29b08d7b618550d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178087942342803&sdata=8tXO0wt5QDXn7BYtVrR4oTvcHfzZor2pMe5%2FGlA%2FLhk%3D&reserved=0
>> > > > >> >
>> > > > >>
>> > > > >> The function seems to be
>> goog.reflect.objectProperty()
>> > > > >>
>> > > > >> I’m not sure exactly how it works though.
>> > > > >>
>> > > > >> > On Jan 16, 2020, at 1:37 AM, Greg Dove <
>> > greg.dove@gmail.com
>> > > >
>> > > wrote:
>> > > > >> >
>> > > > >> > actually just as another fyi, Harbs pointed
>> out some
>> > > intriguing
>> > > goog
>> > > > >> > methods recently - I don't have an immediate
>> > reference to it
>> > > sorry. One
>> > > > >> of
>> > > > >> > those seemed to allow for access to renamed
>> names by
>> > > wrapping the
>> > > > >> original
>> > > > >> > names in a 'magic' method that presumably GCC
>> > recognises
>> > > (but
>> > > presumably
>> > > > >> > returns the name unchanged in debug mode)
>> > > > >> >
>> > > > >> >
>> > > > >> > On Thu, Jan 16, 2020 at 12:33 PM Greg Dove <
>> > > greg.dove@gmail.com>
>> > > wrote:
>> > > > >> >
>> > > > >> >> 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
>> <
>> > > > >> joshtynjala@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%7Cdaafeb6ce92c4ae9f29b08d7b618550d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178087942342803&sdata=z%2FupYdzXPflptLOf73R1CFyBFT8kCMQK5wmovhcB93Y%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%7Cdaafeb6ce92c4ae9f29b08d7b618550d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178087942342803&sdata=9zorxM8uBxGzorkscbCQSjKBKvtUuhAMVXTw6O5BV4E%3D&reserved=0
>> > > >
>> > > > >> >>>
>> > > > >> >>
>> > > > >>
>> > > > >>
>> > > >
>> > > >
>> > > >
>> > >
>> > >
>> > >
>> >
>> >
>> >
>>
>>
>>
Re: MXML and warn-public vars
Posted by Josh Tynjala <jo...@bowlerhat.dev>.
Sorry, yes, of course it's false. Haven't had my morning tea yet.
--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>
On Thu, Feb 20, 2020 at 7:17 AM Josh Tynjala <jo...@bowlerhat.dev>
wrote:
> Do you mean -rename-public-vars=true instead of false? False should
> preserve the original behavior.
>
> --
> Josh Tynjala
> Bowler Hat LLC <https://bowlerhat.dev>
>
>
> On Thu, Feb 20, 2020 at 1:44 AM Alex Harui <ah...@adobe.com.invalid>
> wrote:
>
>> This change is breaking some modules when -rename-public-vars=false.
>> Let's say the main app has some method "foo" that gets renamed. It might
>> accidentally get a minified name that coincides with a public var in the
>> module. For tour de flex, some API gets the minified name "UP". A module
>> has code that references Keyboard.UP.
>>
>> In Pashmina's app, some API gets a minified name like "vs" and the module
>> has a property "vs" (for a ViewStack).
>>
>> We try to allow renaming of APIs in modules for size savings. The list
>> of renames in the main app is output to a file and read into the compiler
>> when compiling the module so it starts with the same renaming map.
>>
>> One thought I had about solving this is to add another compiler option
>> that allows a list of other names to not rename. So for the "UP" scenario,
>> I would compile the main app with, say, -forbidden-minified-names=UP.
>> Folks can probably work around the problem by using Keyboard.UP in the
>> main app, but that bloats the main app. The compiler can already read a
>> file of rename maps, so we could just use that, but I think a simpler
>> command-line list will be more convenient.
>>
>> Thoughts?
>> -Alex
>>
>> On 2/5/20, 12:18 PM, "Josh Tynjala" <jo...@bowlerhat.dev> wrote:
>>
>> Yeah, I'll make sure that users can control whether renaming happens
>> or not.
>>
>> --
>> Josh Tynjala
>> Bowler Hat LLC <
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C8dcbb865725d4151564408d7aa7893c9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637165307165113089&sdata=a5evE514IT0GdVvL7w5IbOCcnyb%2FCwCqgxhOIlJsFvM%3D&reserved=0
>> >
>>
>>
>> On Wed, Feb 5, 2020 at 11:51 AM Alex Harui <ah...@adobe.com.invalid>
>> wrote:
>>
>> > Great work, Josh!
>> >
>> > I have to say that the objectProperty output was adding pain to
>> debugging
>> > so looking forward to that going away. I'm assuming there will be
>> compiler
>> > options/directives to control renaming? I think there are some
>> scenarios
>> > where it is safe to have public variables renamed.
>> >
>> > Thanks,
>> > -Alex
>> >
>> > On 2/5/20, 11:44 AM, "Josh Tynjala" <jo...@bowlerhat.dev>
>> wrote:
>> >
>> > Thank you for the tips, Alex. Much appreciated. With your help,
>> I've
>> > determined how to use Closure compiler's Java API to prevent the
>> > renaming
>> > of a specific public variable that has not been @export-ed.
>> Now, I
>> > should
>> > be able to expand this prototype to a full version that
>> prevents the
>> > renaming of all public variables.
>> >
>> > --
>> > Josh Tynjala
>> > Bowler Hat LLC <
>> >
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C8dcbb865725d4151564408d7aa7893c9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637165307165113089&sdata=a5evE514IT0GdVvL7w5IbOCcnyb%2FCwCqgxhOIlJsFvM%3D&reserved=0
>> > >
>> >
>> >
>> > On Sun, Jan 19, 2020 at 4:58 PM Alex Harui
>> <ah...@adobe.com.invalid>
>> > wrote:
>> >
>> > > In response to your prior post, the reason I am saying it
>> removes
>> > control
>> > > is because I didn't see any option to not have the compiler
>> output
>> > > goog.reflect.objectProperty and I'm not clear everyone will
>> > want/need it.
>> > >
>> > > Regarding how to control Closure Compiler's renaming, the
>> details
>> > might be
>> > > changing because I believe I saw that Google refactored the
>> > renamer. At a
>> > > high-level, you probably know most of this, but for other
>> folks
>> > reading,
>> > > the Closure Compiler is a set of Java Classes that form a
>> series of
>> > > Compiler Passes. Each Pass takes information (sometimes
>> source,
>> > sometimes
>> > > the AST, sometimes other information, and modifies the AST.
>> IIRC, a
>> > final
>> > > pass generates the output. There might be more than one pass
>> for
>> > output.
>> > >
>> > > The renaming pass we currently use can output as well as
>> accept a
>> > file of
>> > > rename mappings. I’m confident we can subclass or modify and
>> > replace the
>> > > renaming pass and feed it a set of mappings. If you look in
>> the
>> > > royale-compiler source, we've already done this for some other
>> > passes.
>> > > Look through the Closure compiler source for what happens to
>> the
>> > compiler
>> > > options:
>> > >
>> > > --variable_map_input_file
>> > > --property_map_input_file
>> > >
>> > > You can build examples/mxroyale/TourDeFlexModules which
>> outputs these
>> > > files to see what is in them.
>> > >
>> > >
>> > > We should also see if we can agree on the scenarios and
>> likelihood of
>> > > property access "by name". I can quickly think of:
>> > >
>> > > A) MXML setting properties by reference (high usage)
>> > > B) MXML setting properties by value (high usage)
>> > > C) Serializers/Deserializers (moderate usage)
>> > > D) [] bracket access by Literal (occasional usage)
>> > > E) [] bracket access by String Variable (occasional usage)
>> > > F) [] bracket access by Expression (infrequent usage)
>> > >
>> > > Exports can solve A. The compiler can easily detect D & E and
>> > prevent
>> > > renaming. For C, we "could" autogenerate exports for any
>> classes
>> > with
>> > > [RemoteClass] metadata or autogenerate getter/setters.
>> > >
>> > > To me, the only difficult case is F and it will rarely happen.
>> > Maybe we
>> > > can detect those and warn on that.
>> > >
>> > > Of course, I could be wrong...
>> > > -Alex
>> > >
>> > >
>> > > On 1/17/20, 10:08 AM, "Josh Tynjala" <
>> joshtynjala@bowlerhat.dev>
>> > wrote:
>> > >
>> > > Comments inline.
>> > >
>> > > On Thursday, January 16, 2020, Alex Harui
>> > <ah...@adobe.com.invalid>
>> > > wrote:
>> > > > Maybe we should start by agreeing on facts and then
>> goals and
>> > then
>> > > discuss solutions.
>> > >
>> > > Yes, I think that's a good place to start.
>> > >
>> > > >
>> > > > Here are some facts that come to mind, not a complete
>> list.
>> > > >
>> > > > 1) An export does not prevent renaming. It builds an
>> alias.
>> > All
>> > > references within the set of sources to be minified are
>> renamed.
>> > >
>> > > Agreed.
>> > >
>> > > > 2) Closure's export mechanism only works on non-scalars
>> > (Object,
>> > > Arrays,
>> > > Functions) and not Number, String, Boolean because
>> non-scalars
>> > are
>> > > pass-by-reference instead of pass-by-value
>> > >
>> > > Agreed.
>> > >
>> > > > 3) The Closure Compiler is open source and designed to
>> be
>> > extended
>> > >
>> > > Agreed.
>> > >
>> > > > 4) Use of goog.reflect.objectProperty is not
>> necessarily the
>> > only
>> > > way to
>> > > control renaming. It is the way recommended by Google
>> for those
>> > who
>> > > can't
>> > > extend the compiler. We are not constrained to modify
>> our output
>> > > because
>> > > we have control over the compiler.
>> > >
>> > > Could you share some details how we might have more
>> control over
>> > > Closure
>> > > compiler's renaming? It sounds like you know, at least
>> somewhat,
>> > how
>> > > to use
>> > > its lower-level Java APIs, but you've never shared the
>> details
>> > when
>> > > you've
>> > > mentioned them in this thread or in the past.
>> > >
>> > > I should add that I've personally tried to research this
>> topic
>> > myself,
>> > > but
>> > > I had a very hard time finding any information that
>> wasn't just
>> > someone
>> > > explaining to a JS developer that they needed to modify
>> their JS
>> > code.
>> > > I
>> > > eventually couldn't justify spending more time to keep
>> looking.
>> > >
>> > > > 5) The compiler knows things about how properties were
>> > accessed.
>> > > That
>> > > information is lost in the output in many cases.
>> Therefore, it
>> > should
>> > > be
>> > > better to inform the Google minifier directly from the
>> Royale
>> > compiler,
>> > > instead of leaving hints in the output.
>> > >
>> > > Agreed. I'm personally not fully convinced that the Royale
>> > compiler has
>> > > enough information for dynamic stuff (like for
>> serialization
>> > with type
>> > > Object), but that may be due to ignorance about Closure
>> > compiler's
>> > > capabilities. Even without knowing how it works, I can
>> imagine
>> > how it
>> > > might
>> > > be relatively easy to prevent renaming of public
>> variables, but
>> > the
>> > > dynamic
>> > > stuff is trickier. For the dynamic stuff, maybe it's just
>> a
>> > matter of
>> > > Closure detecting when a variable is typed as Object, and
>> then
>> > it can
>> > > switch to ["string"] syntax on its own (instead of us
>> doing it
>> > in the
>> > > debug
>> > > build, like with -js-dynamic-access-unknown-members).
>> > >
>> > > > 7) We are pretty close to allowing renaming across
>> modules.
>> > It was
>> > > working for a while, but a scenario popped up that isn't
>> > currently
>> > > handled. We can pre-load the Closure renamer with a name
>> map.
>> > >
>> > > I haven't looked in detail at the module implementation
>> and
>> > don't plan
>> > > to,
>> > > but I understand it well enough at a high level to say
>> "agreed"
>> > here
>> > > too
>> > >
>> > > >
>> > > > These are hypotheses, and not proven facts.
>> > > > 8) The big gain from not exporting everything is in
>> dead code
>> > removal
>> > > instead of shorter variable names
>> > >
>> > > Agreed, personally. It seems like others have expressed
>> interest
>> > in
>> > > both,
>> > > though. I hope that they'll be willing to prioriitze dead
>> code
>> > removal,
>> > > since it will probably have the bigger impact (my own
>> tests
>> > removing
>> > > @export have been promising in this regard).
>> > >
>> > > > 9) Renaming can complicate and slow
>> > serialization/deserialization
>> > >
>> > > Agreed, and this is the harder portion to get working, I
>> think.
>> > >
>> > > However, if release builds didn't rename public
>> variables, and
>> > also
>> > > didn't
>> > > rename dynamic accesses, that would remove my biggest
>> > frustration with
>> > > how
>> > > ActionScript works in Royale/JS compared to SWF. If both
>> kept
>> > their
>> > > original names, things that feel broken today would "just
>> work"
>> > again.
>> > >
>> > > >
>> > > > IMO, we want to be heading in the direction of A)
>> allowing
>> > control
>> > > over
>> > > what gets renamed
>> > >
>> > > Agreed, but as I said before, I think that dead code
>> removal
>> > will have
>> > > more
>> > > impact than control over renaming, so if it's one or the
>> other,
>> > I'm
>> > > okay
>> > > with no control over renaming.
>> > >
>> > > > B) capturing information from the compiler,
>> > > > C) controlling the set of renames and exports directly,
>> not
>> > through
>> > > the
>> > > output.
>> > >
>> > > Agreed, being able to pass information Closure compiler
>> on the
>> > Java
>> > > side
>> > > would be better. than through the JS output
>> > >
>> > >
>> > > >
>> > > > My 2 cents,
>> > > > -Alex
>> > > >
>> > > >
>> > > > On 1/16/20, 2:48 PM, "Josh Tynjala" <
>> joshtynjala@bowlerhat.dev
>> > >
>> > > wrote:
>> > > >
>> > > > Some additional context, if anyone is interested.
>> > > >
>> > > > At the request of Harbs, I am currently
>> investigating how
>> > we
>> > > might
>> > > remove
>> > > > @export from our generated JS code to improve the
>> > minimization
>> > > even
>> > > more.
>> > > > When I modified the compiler to skip emitting
>> @export in
>> > some
>> > > places,
>> > > a
>> > > > release build of TourDeJewel was initially broken.
>> When I
>> > added
>> > > > goog.reflect.objectProperty(), not only did it fix
>> setting
>> > public
>> > > variables
>> > > > in MXML, it also made that release build of
>> TourDeJewel
>> > start
>> > > working
>> > > again.
>> > > >
>> > > > --
>> > > > Josh Tynjala
>> > > > Bowler Hat LLC <
>> > >
>> > >
>> >
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C8dcbb865725d4151564408d7aa7893c9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637165307165113089&sdata=a5evE514IT0GdVvL7w5IbOCcnyb%2FCwCqgxhOIlJsFvM%3D&reserved=0
>> > > >
>> > > >
>> > > >
>> > > > On Thu, Jan 16, 2020 at 12:59 PM Josh Tynjala <
>> > > joshtynjala@bowlerhat.dev>
>> > > > wrote:
>> > > >
>> > > > > Thank you, Harbs! Wrapping the variable name in a
>> > > > > goog.reflect.objectProperty() call works
>> perfectly. This
>> > is
>> > > exactly
>> > > why I
>> > > > > started this thread, to see if anyone could
>> suggest
>> > possible
>> > > alternatives.
>> > > > >
>> > > > > Thankfully, we can keep the same simple data
>> structure as
>> > > before,
>> > > and my
>> > > > > initial proposal with functions can be forgotten.
>> In a
>> > release
>> > > build, I can
>> > > > > see that goog.reflect.objectProperty() calls are
>> > replaced by a
>> > > simple
>> > > > > string literal (containing the minified variable
>> name),
>> > so we
>> > > don't
>> > > have to
>> > > > > worry about extra performance impact.
>> > > > >
>> > > > > --
>> > > > > Josh Tynjala
>> > > > > Bowler Hat LLC <
>> > >
>> > >
>> >
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C8dcbb865725d4151564408d7aa7893c9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637165307165113089&sdata=a5evE514IT0GdVvL7w5IbOCcnyb%2FCwCqgxhOIlJsFvM%3D&reserved=0
>> > > >
>> > > > >
>> > > > >
>> > > > > On Wed, Jan 15, 2020 at 8:32 PM Harbs <
>> > harbs.lists@gmail.com>
>> > > wrote:
>> > > > >
>> > > > >> Sounds good!
>> > > > >>
>> > > > >>
>> > > > >>
>> > >
>> > >
>> >
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FType-Based-Property-Renaming&data=02%7C01%7Caharui%40adobe.com%7C8dcbb865725d4151564408d7aa7893c9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637165307165113089&sdata=O5PMzmZaDJnnWfkJL1EQMlGudNjREP88VIbImidkXtw%3D&reserved=0
>> > > > >> <
>> > > > >>
>> > >
>> > >
>> >
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FType-Based-Property-Renaming&data=02%7C01%7Caharui%40adobe.com%7C8dcbb865725d4151564408d7aa7893c9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637165307165113089&sdata=O5PMzmZaDJnnWfkJL1EQMlGudNjREP88VIbImidkXtw%3D&reserved=0
>> > > > >> >
>> > > > >>
>> > > > >> The function seems to be
>> goog.reflect.objectProperty()
>> > > > >>
>> > > > >> I’m not sure exactly how it works though.
>> > > > >>
>> > > > >> > On Jan 16, 2020, at 1:37 AM, Greg Dove <
>> > greg.dove@gmail.com
>> > > >
>> > > wrote:
>> > > > >> >
>> > > > >> > actually just as another fyi, Harbs pointed
>> out some
>> > > intriguing
>> > > goog
>> > > > >> > methods recently - I don't have an immediate
>> > reference to it
>> > > sorry. One
>> > > > >> of
>> > > > >> > those seemed to allow for access to renamed
>> names by
>> > > wrapping the
>> > > > >> original
>> > > > >> > names in a 'magic' method that presumably GCC
>> > recognises
>> > > (but
>> > > presumably
>> > > > >> > returns the name unchanged in debug mode)
>> > > > >> >
>> > > > >> >
>> > > > >> > On Thu, Jan 16, 2020 at 12:33 PM Greg Dove <
>> > > greg.dove@gmail.com>
>> > > wrote:
>> > > > >> >
>> > > > >> >> 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
>> <
>> > > > >> joshtynjala@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%7C8dcbb865725d4151564408d7aa7893c9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637165307165113089&sdata=M%2BEvAma5g8ufQL0Nf2Krb3hrr2ERTHhdsofqVUhm7f4%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%7C8dcbb865725d4151564408d7aa7893c9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637165307165113089&sdata=a5evE514IT0GdVvL7w5IbOCcnyb%2FCwCqgxhOIlJsFvM%3D&reserved=0
>> > > >
>> > > > >> >>>
>> > > > >> >>
>> > > > >>
>> > > > >>
>> > > >
>> > > >
>> > > >
>> > >
>> > >
>> > >
>> >
>> >
>> >
>>
>>
>>
Re: MXML and warn-public vars
Posted by Josh Tynjala <jo...@bowlerhat.dev>.
Do you mean -rename-public-vars=true instead of false? False should
preserve the original behavior.
--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>
On Thu, Feb 20, 2020 at 1:44 AM Alex Harui <ah...@adobe.com.invalid> wrote:
> This change is breaking some modules when -rename-public-vars=false.
> Let's say the main app has some method "foo" that gets renamed. It might
> accidentally get a minified name that coincides with a public var in the
> module. For tour de flex, some API gets the minified name "UP". A module
> has code that references Keyboard.UP.
>
> In Pashmina's app, some API gets a minified name like "vs" and the module
> has a property "vs" (for a ViewStack).
>
> We try to allow renaming of APIs in modules for size savings. The list of
> renames in the main app is output to a file and read into the compiler when
> compiling the module so it starts with the same renaming map.
>
> One thought I had about solving this is to add another compiler option
> that allows a list of other names to not rename. So for the "UP" scenario,
> I would compile the main app with, say, -forbidden-minified-names=UP.
> Folks can probably work around the problem by using Keyboard.UP in the
> main app, but that bloats the main app. The compiler can already read a
> file of rename maps, so we could just use that, but I think a simpler
> command-line list will be more convenient.
>
> Thoughts?
> -Alex
>
> On 2/5/20, 12:18 PM, "Josh Tynjala" <jo...@bowlerhat.dev> wrote:
>
> Yeah, I'll make sure that users can control whether renaming happens
> or not.
>
> --
> Josh Tynjala
> Bowler Hat LLC <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C8dcbb865725d4151564408d7aa7893c9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637165307165113089&sdata=a5evE514IT0GdVvL7w5IbOCcnyb%2FCwCqgxhOIlJsFvM%3D&reserved=0
> >
>
>
> On Wed, Feb 5, 2020 at 11:51 AM Alex Harui <ah...@adobe.com.invalid>
> wrote:
>
> > Great work, Josh!
> >
> > I have to say that the objectProperty output was adding pain to
> debugging
> > so looking forward to that going away. I'm assuming there will be
> compiler
> > options/directives to control renaming? I think there are some
> scenarios
> > where it is safe to have public variables renamed.
> >
> > Thanks,
> > -Alex
> >
> > On 2/5/20, 11:44 AM, "Josh Tynjala" <jo...@bowlerhat.dev>
> wrote:
> >
> > Thank you for the tips, Alex. Much appreciated. With your help,
> I've
> > determined how to use Closure compiler's Java API to prevent the
> > renaming
> > of a specific public variable that has not been @export-ed. Now,
> I
> > should
> > be able to expand this prototype to a full version that prevents
> the
> > renaming of all public variables.
> >
> > --
> > Josh Tynjala
> > Bowler Hat LLC <
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C8dcbb865725d4151564408d7aa7893c9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637165307165113089&sdata=a5evE514IT0GdVvL7w5IbOCcnyb%2FCwCqgxhOIlJsFvM%3D&reserved=0
> > >
> >
> >
> > On Sun, Jan 19, 2020 at 4:58 PM Alex Harui
> <ah...@adobe.com.invalid>
> > wrote:
> >
> > > In response to your prior post, the reason I am saying it
> removes
> > control
> > > is because I didn't see any option to not have the compiler
> output
> > > goog.reflect.objectProperty and I'm not clear everyone will
> > want/need it.
> > >
> > > Regarding how to control Closure Compiler's renaming, the
> details
> > might be
> > > changing because I believe I saw that Google refactored the
> > renamer. At a
> > > high-level, you probably know most of this, but for other folks
> > reading,
> > > the Closure Compiler is a set of Java Classes that form a
> series of
> > > Compiler Passes. Each Pass takes information (sometimes
> source,
> > sometimes
> > > the AST, sometimes other information, and modifies the AST.
> IIRC, a
> > final
> > > pass generates the output. There might be more than one pass
> for
> > output.
> > >
> > > The renaming pass we currently use can output as well as
> accept a
> > file of
> > > rename mappings. I’m confident we can subclass or modify and
> > replace the
> > > renaming pass and feed it a set of mappings. If you look in
> the
> > > royale-compiler source, we've already done this for some other
> > passes.
> > > Look through the Closure compiler source for what happens to
> the
> > compiler
> > > options:
> > >
> > > --variable_map_input_file
> > > --property_map_input_file
> > >
> > > You can build examples/mxroyale/TourDeFlexModules which
> outputs these
> > > files to see what is in them.
> > >
> > >
> > > We should also see if we can agree on the scenarios and
> likelihood of
> > > property access "by name". I can quickly think of:
> > >
> > > A) MXML setting properties by reference (high usage)
> > > B) MXML setting properties by value (high usage)
> > > C) Serializers/Deserializers (moderate usage)
> > > D) [] bracket access by Literal (occasional usage)
> > > E) [] bracket access by String Variable (occasional usage)
> > > F) [] bracket access by Expression (infrequent usage)
> > >
> > > Exports can solve A. The compiler can easily detect D & E and
> > prevent
> > > renaming. For C, we "could" autogenerate exports for any
> classes
> > with
> > > [RemoteClass] metadata or autogenerate getter/setters.
> > >
> > > To me, the only difficult case is F and it will rarely happen.
> > Maybe we
> > > can detect those and warn on that.
> > >
> > > Of course, I could be wrong...
> > > -Alex
> > >
> > >
> > > On 1/17/20, 10:08 AM, "Josh Tynjala" <
> joshtynjala@bowlerhat.dev>
> > wrote:
> > >
> > > Comments inline.
> > >
> > > On Thursday, January 16, 2020, Alex Harui
> > <ah...@adobe.com.invalid>
> > > wrote:
> > > > Maybe we should start by agreeing on facts and then
> goals and
> > then
> > > discuss solutions.
> > >
> > > Yes, I think that's a good place to start.
> > >
> > > >
> > > > Here are some facts that come to mind, not a complete
> list.
> > > >
> > > > 1) An export does not prevent renaming. It builds an
> alias.
> > All
> > > references within the set of sources to be minified are
> renamed.
> > >
> > > Agreed.
> > >
> > > > 2) Closure's export mechanism only works on non-scalars
> > (Object,
> > > Arrays,
> > > Functions) and not Number, String, Boolean because
> non-scalars
> > are
> > > pass-by-reference instead of pass-by-value
> > >
> > > Agreed.
> > >
> > > > 3) The Closure Compiler is open source and designed to be
> > extended
> > >
> > > Agreed.
> > >
> > > > 4) Use of goog.reflect.objectProperty is not necessarily
> the
> > only
> > > way to
> > > control renaming. It is the way recommended by Google for
> those
> > who
> > > can't
> > > extend the compiler. We are not constrained to modify our
> output
> > > because
> > > we have control over the compiler.
> > >
> > > Could you share some details how we might have more
> control over
> > > Closure
> > > compiler's renaming? It sounds like you know, at least
> somewhat,
> > how
> > > to use
> > > its lower-level Java APIs, but you've never shared the
> details
> > when
> > > you've
> > > mentioned them in this thread or in the past.
> > >
> > > I should add that I've personally tried to research this
> topic
> > myself,
> > > but
> > > I had a very hard time finding any information that wasn't
> just
> > someone
> > > explaining to a JS developer that they needed to modify
> their JS
> > code.
> > > I
> > > eventually couldn't justify spending more time to keep
> looking.
> > >
> > > > 5) The compiler knows things about how properties were
> > accessed.
> > > That
> > > information is lost in the output in many cases.
> Therefore, it
> > should
> > > be
> > > better to inform the Google minifier directly from the
> Royale
> > compiler,
> > > instead of leaving hints in the output.
> > >
> > > Agreed. I'm personally not fully convinced that the Royale
> > compiler has
> > > enough information for dynamic stuff (like for
> serialization
> > with type
> > > Object), but that may be due to ignorance about Closure
> > compiler's
> > > capabilities. Even without knowing how it works, I can
> imagine
> > how it
> > > might
> > > be relatively easy to prevent renaming of public
> variables, but
> > the
> > > dynamic
> > > stuff is trickier. For the dynamic stuff, maybe it's just a
> > matter of
> > > Closure detecting when a variable is typed as Object, and
> then
> > it can
> > > switch to ["string"] syntax on its own (instead of us
> doing it
> > in the
> > > debug
> > > build, like with -js-dynamic-access-unknown-members).
> > >
> > > > 7) We are pretty close to allowing renaming across
> modules.
> > It was
> > > working for a while, but a scenario popped up that isn't
> > currently
> > > handled. We can pre-load the Closure renamer with a name
> map.
> > >
> > > I haven't looked in detail at the module implementation and
> > don't plan
> > > to,
> > > but I understand it well enough at a high level to say
> "agreed"
> > here
> > > too
> > >
> > > >
> > > > These are hypotheses, and not proven facts.
> > > > 8) The big gain from not exporting everything is in dead
> code
> > removal
> > > instead of shorter variable names
> > >
> > > Agreed, personally. It seems like others have expressed
> interest
> > in
> > > both,
> > > though. I hope that they'll be willing to prioriitze dead
> code
> > removal,
> > > since it will probably have the bigger impact (my own tests
> > removing
> > > @export have been promising in this regard).
> > >
> > > > 9) Renaming can complicate and slow
> > serialization/deserialization
> > >
> > > Agreed, and this is the harder portion to get working, I
> think.
> > >
> > > However, if release builds didn't rename public variables,
> and
> > also
> > > didn't
> > > rename dynamic accesses, that would remove my biggest
> > frustration with
> > > how
> > > ActionScript works in Royale/JS compared to SWF. If both
> kept
> > their
> > > original names, things that feel broken today would "just
> work"
> > again.
> > >
> > > >
> > > > IMO, we want to be heading in the direction of A)
> allowing
> > control
> > > over
> > > what gets renamed
> > >
> > > Agreed, but as I said before, I think that dead code
> removal
> > will have
> > > more
> > > impact than control over renaming, so if it's one or the
> other,
> > I'm
> > > okay
> > > with no control over renaming.
> > >
> > > > B) capturing information from the compiler,
> > > > C) controlling the set of renames and exports directly,
> not
> > through
> > > the
> > > output.
> > >
> > > Agreed, being able to pass information Closure compiler on
> the
> > Java
> > > side
> > > would be better. than through the JS output
> > >
> > >
> > > >
> > > > My 2 cents,
> > > > -Alex
> > > >
> > > >
> > > > On 1/16/20, 2:48 PM, "Josh Tynjala" <
> joshtynjala@bowlerhat.dev
> > >
> > > wrote:
> > > >
> > > > Some additional context, if anyone is interested.
> > > >
> > > > At the request of Harbs, I am currently
> investigating how
> > we
> > > might
> > > remove
> > > > @export from our generated JS code to improve the
> > minimization
> > > even
> > > more.
> > > > When I modified the compiler to skip emitting
> @export in
> > some
> > > places,
> > > a
> > > > release build of TourDeJewel was initially broken.
> When I
> > added
> > > > goog.reflect.objectProperty(), not only did it fix
> setting
> > public
> > > variables
> > > > in MXML, it also made that release build of
> TourDeJewel
> > start
> > > working
> > > again.
> > > >
> > > > --
> > > > Josh Tynjala
> > > > Bowler Hat LLC <
> > >
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C8dcbb865725d4151564408d7aa7893c9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637165307165113089&sdata=a5evE514IT0GdVvL7w5IbOCcnyb%2FCwCqgxhOIlJsFvM%3D&reserved=0
> > > >
> > > >
> > > >
> > > > On Thu, Jan 16, 2020 at 12:59 PM Josh Tynjala <
> > > joshtynjala@bowlerhat.dev>
> > > > wrote:
> > > >
> > > > > Thank you, Harbs! Wrapping the variable name in a
> > > > > goog.reflect.objectProperty() call works
> perfectly. This
> > is
> > > exactly
> > > why I
> > > > > started this thread, to see if anyone could suggest
> > possible
> > > alternatives.
> > > > >
> > > > > Thankfully, we can keep the same simple data
> structure as
> > > before,
> > > and my
> > > > > initial proposal with functions can be forgotten.
> In a
> > release
> > > build, I can
> > > > > see that goog.reflect.objectProperty() calls are
> > replaced by a
> > > simple
> > > > > string literal (containing the minified variable
> name),
> > so we
> > > don't
> > > have to
> > > > > worry about extra performance impact.
> > > > >
> > > > > --
> > > > > Josh Tynjala
> > > > > Bowler Hat LLC <
> > >
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C8dcbb865725d4151564408d7aa7893c9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637165307165113089&sdata=a5evE514IT0GdVvL7w5IbOCcnyb%2FCwCqgxhOIlJsFvM%3D&reserved=0
> > > >
> > > > >
> > > > >
> > > > > On Wed, Jan 15, 2020 at 8:32 PM Harbs <
> > harbs.lists@gmail.com>
> > > wrote:
> > > > >
> > > > >> Sounds good!
> > > > >>
> > > > >>
> > > > >>
> > >
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FType-Based-Property-Renaming&data=02%7C01%7Caharui%40adobe.com%7C8dcbb865725d4151564408d7aa7893c9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637165307165113089&sdata=O5PMzmZaDJnnWfkJL1EQMlGudNjREP88VIbImidkXtw%3D&reserved=0
> > > > >> <
> > > > >>
> > >
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FType-Based-Property-Renaming&data=02%7C01%7Caharui%40adobe.com%7C8dcbb865725d4151564408d7aa7893c9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637165307165113089&sdata=O5PMzmZaDJnnWfkJL1EQMlGudNjREP88VIbImidkXtw%3D&reserved=0
> > > > >> >
> > > > >>
> > > > >> The function seems to be
> goog.reflect.objectProperty()
> > > > >>
> > > > >> I’m not sure exactly how it works though.
> > > > >>
> > > > >> > On Jan 16, 2020, at 1:37 AM, Greg Dove <
> > greg.dove@gmail.com
> > > >
> > > wrote:
> > > > >> >
> > > > >> > actually just as another fyi, Harbs pointed out
> some
> > > intriguing
> > > goog
> > > > >> > methods recently - I don't have an immediate
> > reference to it
> > > sorry. One
> > > > >> of
> > > > >> > those seemed to allow for access to renamed
> names by
> > > wrapping the
> > > > >> original
> > > > >> > names in a 'magic' method that presumably GCC
> > recognises
> > > (but
> > > presumably
> > > > >> > returns the name unchanged in debug mode)
> > > > >> >
> > > > >> >
> > > > >> > On Thu, Jan 16, 2020 at 12:33 PM Greg Dove <
> > > greg.dove@gmail.com>
> > > wrote:
> > > > >> >
> > > > >> >> 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 <
> > > > >> joshtynjala@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%7C8dcbb865725d4151564408d7aa7893c9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637165307165113089&sdata=M%2BEvAma5g8ufQL0Nf2Krb3hrr2ERTHhdsofqVUhm7f4%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%7C8dcbb865725d4151564408d7aa7893c9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637165307165113089&sdata=a5evE514IT0GdVvL7w5IbOCcnyb%2FCwCqgxhOIlJsFvM%3D&reserved=0
> > > >
> > > > >> >>>
> > > > >> >>
> > > > >>
> > > > >>
> > > >
> > > >
> > > >
> > >
> > >
> > >
> >
> >
> >
>
>
>
Re: MXML and warn-public vars
Posted by Alex Harui <ah...@adobe.com.INVALID>.
On 2/20/20, 6:50 AM, "Carlos Rovira" <ca...@apache.org> wrote:
Hi Alex,
I think this should transparent for the final user and not need to add a
compiler option, just configure all the strings that can cause problems,
since for what I understand the problem, we can know what strings are
problematic, right?
You don't know what strings are problematic when compiling the application. You only find out when you later compile the module. The only solution I've thought of so far is to allow a list of reserved names when compiling the application so avoid collisions when compiling the module. You "can" add code to the application to reserve that string but that adds weight to the application, and you have to add that code in a way it is not seen as dead code and removed.
TourDeFlexMigration is currently not building for this very reason. I might try to find a pattern to add code to the application, if I find some time, but I think reserving a list of names is probably best.
-Alex
Thanks
El jue., 20 feb. 2020 a las 10:44, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> This change is breaking some modules when -rename-public-vars=false.
> Let's say the main app has some method "foo" that gets renamed. It might
> accidentally get a minified name that coincides with a public var in the
> module. For tour de flex, some API gets the minified name "UP". A module
> has code that references Keyboard.UP.
>
> In Pashmina's app, some API gets a minified name like "vs" and the module
> has a property "vs" (for a ViewStack).
>
> We try to allow renaming of APIs in modules for size savings. The list of
> renames in the main app is output to a file and read into the compiler when
> compiling the module so it starts with the same renaming map.
>
> One thought I had about solving this is to add another compiler option
> that allows a list of other names to not rename. So for the "UP" scenario,
> I would compile the main app with, say, -forbidden-minified-names=UP.
> Folks can probably work around the problem by using Keyboard.UP in the
> main app, but that bloats the main app. The compiler can already read a
> file of rename maps, so we could just use that, but I think a simpler
> command-line list will be more convenient.
>
> Thoughts?
> -Alex
>
> On 2/5/20, 12:18 PM, "Josh Tynjala" <jo...@bowlerhat.dev> wrote:
>
> Yeah, I'll make sure that users can control whether renaming happens
> or not.
>
> --
> Josh Tynjala
> Bowler Hat LLC <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C8837468e7a2e4344564b08d7b6142ec7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178070124083456&sdata=rPzChKqkUGUPyf94NhLBfIQRFmxGnTuQ6%2FQOi1ux2J0%3D&reserved=0
> >
>
>
> On Wed, Feb 5, 2020 at 11:51 AM Alex Harui <ah...@adobe.com.invalid>
> wrote:
>
> > Great work, Josh!
> >
> > I have to say that the objectProperty output was adding pain to
> debugging
> > so looking forward to that going away. I'm assuming there will be
> compiler
> > options/directives to control renaming? I think there are some
> scenarios
> > where it is safe to have public variables renamed.
> >
> > Thanks,
> > -Alex
> >
> > On 2/5/20, 11:44 AM, "Josh Tynjala" <jo...@bowlerhat.dev>
> wrote:
> >
> > Thank you for the tips, Alex. Much appreciated. With your help,
> I've
> > determined how to use Closure compiler's Java API to prevent the
> > renaming
> > of a specific public variable that has not been @export-ed. Now,
> I
> > should
> > be able to expand this prototype to a full version that prevents
> the
> > renaming of all public variables.
> >
> > --
> > Josh Tynjala
> > Bowler Hat LLC <
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C8837468e7a2e4344564b08d7b6142ec7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178070124093456&sdata=pA01nbT%2BFHtnISBm9Fn1cq2HMR1jjrje9VWHKQfQ7vc%3D&reserved=0
> > >
> >
> >
> > On Sun, Jan 19, 2020 at 4:58 PM Alex Harui
> <ah...@adobe.com.invalid>
> > wrote:
> >
> > > In response to your prior post, the reason I am saying it
> removes
> > control
> > > is because I didn't see any option to not have the compiler
> output
> > > goog.reflect.objectProperty and I'm not clear everyone will
> > want/need it.
> > >
> > > Regarding how to control Closure Compiler's renaming, the
> details
> > might be
> > > changing because I believe I saw that Google refactored the
> > renamer. At a
> > > high-level, you probably know most of this, but for other folks
> > reading,
> > > the Closure Compiler is a set of Java Classes that form a
> series of
> > > Compiler Passes. Each Pass takes information (sometimes
> source,
> > sometimes
> > > the AST, sometimes other information, and modifies the AST.
> IIRC, a
> > final
> > > pass generates the output. There might be more than one pass
> for
> > output.
> > >
> > > The renaming pass we currently use can output as well as
> accept a
> > file of
> > > rename mappings. I’m confident we can subclass or modify and
> > replace the
> > > renaming pass and feed it a set of mappings. If you look in
> the
> > > royale-compiler source, we've already done this for some other
> > passes.
> > > Look through the Closure compiler source for what happens to
> the
> > compiler
> > > options:
> > >
> > > --variable_map_input_file
> > > --property_map_input_file
> > >
> > > You can build examples/mxroyale/TourDeFlexModules which
> outputs these
> > > files to see what is in them.
> > >
> > >
> > > We should also see if we can agree on the scenarios and
> likelihood of
> > > property access "by name". I can quickly think of:
> > >
> > > A) MXML setting properties by reference (high usage)
> > > B) MXML setting properties by value (high usage)
> > > C) Serializers/Deserializers (moderate usage)
> > > D) [] bracket access by Literal (occasional usage)
> > > E) [] bracket access by String Variable (occasional usage)
> > > F) [] bracket access by Expression (infrequent usage)
> > >
> > > Exports can solve A. The compiler can easily detect D & E and
> > prevent
> > > renaming. For C, we "could" autogenerate exports for any
> classes
> > with
> > > [RemoteClass] metadata or autogenerate getter/setters.
> > >
> > > To me, the only difficult case is F and it will rarely happen.
> > Maybe we
> > > can detect those and warn on that.
> > >
> > > Of course, I could be wrong...
> > > -Alex
> > >
> > >
> > > On 1/17/20, 10:08 AM, "Josh Tynjala" <
> joshtynjala@bowlerhat.dev>
> > wrote:
> > >
> > > Comments inline.
> > >
> > > On Thursday, January 16, 2020, Alex Harui
> > <ah...@adobe.com.invalid>
> > > wrote:
> > > > Maybe we should start by agreeing on facts and then
> goals and
> > then
> > > discuss solutions.
> > >
> > > Yes, I think that's a good place to start.
> > >
> > > >
> > > > Here are some facts that come to mind, not a complete
> list.
> > > >
> > > > 1) An export does not prevent renaming. It builds an
> alias.
> > All
> > > references within the set of sources to be minified are
> renamed.
> > >
> > > Agreed.
> > >
> > > > 2) Closure's export mechanism only works on non-scalars
> > (Object,
> > > Arrays,
> > > Functions) and not Number, String, Boolean because
> non-scalars
> > are
> > > pass-by-reference instead of pass-by-value
> > >
> > > Agreed.
> > >
> > > > 3) The Closure Compiler is open source and designed to be
> > extended
> > >
> > > Agreed.
> > >
> > > > 4) Use of goog.reflect.objectProperty is not necessarily
> the
> > only
> > > way to
> > > control renaming. It is the way recommended by Google for
> those
> > who
> > > can't
> > > extend the compiler. We are not constrained to modify our
> output
> > > because
> > > we have control over the compiler.
> > >
> > > Could you share some details how we might have more
> control over
> > > Closure
> > > compiler's renaming? It sounds like you know, at least
> somewhat,
> > how
> > > to use
> > > its lower-level Java APIs, but you've never shared the
> details
> > when
> > > you've
> > > mentioned them in this thread or in the past.
> > >
> > > I should add that I've personally tried to research this
> topic
> > myself,
> > > but
> > > I had a very hard time finding any information that wasn't
> just
> > someone
> > > explaining to a JS developer that they needed to modify
> their JS
> > code.
> > > I
> > > eventually couldn't justify spending more time to keep
> looking.
> > >
> > > > 5) The compiler knows things about how properties were
> > accessed.
> > > That
> > > information is lost in the output in many cases.
> Therefore, it
> > should
> > > be
> > > better to inform the Google minifier directly from the
> Royale
> > compiler,
> > > instead of leaving hints in the output.
> > >
> > > Agreed. I'm personally not fully convinced that the Royale
> > compiler has
> > > enough information for dynamic stuff (like for
> serialization
> > with type
> > > Object), but that may be due to ignorance about Closure
> > compiler's
> > > capabilities. Even without knowing how it works, I can
> imagine
> > how it
> > > might
> > > be relatively easy to prevent renaming of public
> variables, but
> > the
> > > dynamic
> > > stuff is trickier. For the dynamic stuff, maybe it's just a
> > matter of
> > > Closure detecting when a variable is typed as Object, and
> then
> > it can
> > > switch to ["string"] syntax on its own (instead of us
> doing it
> > in the
> > > debug
> > > build, like with -js-dynamic-access-unknown-members).
> > >
> > > > 7) We are pretty close to allowing renaming across
> modules.
> > It was
> > > working for a while, but a scenario popped up that isn't
> > currently
> > > handled. We can pre-load the Closure renamer with a name
> map.
> > >
> > > I haven't looked in detail at the module implementation and
> > don't plan
> > > to,
> > > but I understand it well enough at a high level to say
> "agreed"
> > here
> > > too
> > >
> > > >
> > > > These are hypotheses, and not proven facts.
> > > > 8) The big gain from not exporting everything is in dead
> code
> > removal
> > > instead of shorter variable names
> > >
> > > Agreed, personally. It seems like others have expressed
> interest
> > in
> > > both,
> > > though. I hope that they'll be willing to prioriitze dead
> code
> > removal,
> > > since it will probably have the bigger impact (my own tests
> > removing
> > > @export have been promising in this regard).
> > >
> > > > 9) Renaming can complicate and slow
> > serialization/deserialization
> > >
> > > Agreed, and this is the harder portion to get working, I
> think.
> > >
> > > However, if release builds didn't rename public variables,
> and
> > also
> > > didn't
> > > rename dynamic accesses, that would remove my biggest
> > frustration with
> > > how
> > > ActionScript works in Royale/JS compared to SWF. If both
> kept
> > their
> > > original names, things that feel broken today would "just
> work"
> > again.
> > >
> > > >
> > > > IMO, we want to be heading in the direction of A)
> allowing
> > control
> > > over
> > > what gets renamed
> > >
> > > Agreed, but as I said before, I think that dead code
> removal
> > will have
> > > more
> > > impact than control over renaming, so if it's one or the
> other,
> > I'm
> > > okay
> > > with no control over renaming.
> > >
> > > > B) capturing information from the compiler,
> > > > C) controlling the set of renames and exports directly,
> not
> > through
> > > the
> > > output.
> > >
> > > Agreed, being able to pass information Closure compiler on
> the
> > Java
> > > side
> > > would be better. than through the JS output
> > >
> > >
> > > >
> > > > My 2 cents,
> > > > -Alex
> > > >
> > > >
> > > > On 1/16/20, 2:48 PM, "Josh Tynjala" <
> joshtynjala@bowlerhat.dev
> > >
> > > wrote:
> > > >
> > > > Some additional context, if anyone is interested.
> > > >
> > > > At the request of Harbs, I am currently
> investigating how
> > we
> > > might
> > > remove
> > > > @export from our generated JS code to improve the
> > minimization
> > > even
> > > more.
> > > > When I modified the compiler to skip emitting
> @export in
> > some
> > > places,
> > > a
> > > > release build of TourDeJewel was initially broken.
> When I
> > added
> > > > goog.reflect.objectProperty(), not only did it fix
> setting
> > public
> > > variables
> > > > in MXML, it also made that release build of
> TourDeJewel
> > start
> > > working
> > > again.
> > > >
> > > > --
> > > > Josh Tynjala
> > > > Bowler Hat LLC <
> > >
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C8837468e7a2e4344564b08d7b6142ec7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178070124093456&sdata=pA01nbT%2BFHtnISBm9Fn1cq2HMR1jjrje9VWHKQfQ7vc%3D&reserved=0
> > > >
> > > >
> > > >
> > > > On Thu, Jan 16, 2020 at 12:59 PM Josh Tynjala <
> > > joshtynjala@bowlerhat.dev>
> > > > wrote:
> > > >
> > > > > Thank you, Harbs! Wrapping the variable name in a
> > > > > goog.reflect.objectProperty() call works
> perfectly. This
> > is
> > > exactly
> > > why I
> > > > > started this thread, to see if anyone could suggest
> > possible
> > > alternatives.
> > > > >
> > > > > Thankfully, we can keep the same simple data
> structure as
> > > before,
> > > and my
> > > > > initial proposal with functions can be forgotten.
> In a
> > release
> > > build, I can
> > > > > see that goog.reflect.objectProperty() calls are
> > replaced by a
> > > simple
> > > > > string literal (containing the minified variable
> name),
> > so we
> > > don't
> > > have to
> > > > > worry about extra performance impact.
> > > > >
> > > > > --
> > > > > Josh Tynjala
> > > > > Bowler Hat LLC <
> > >
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C8837468e7a2e4344564b08d7b6142ec7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178070124093456&sdata=pA01nbT%2BFHtnISBm9Fn1cq2HMR1jjrje9VWHKQfQ7vc%3D&reserved=0
> > > >
> > > > >
> > > > >
> > > > > On Wed, Jan 15, 2020 at 8:32 PM Harbs <
> > harbs.lists@gmail.com>
> > > wrote:
> > > > >
> > > > >> Sounds good!
> > > > >>
> > > > >>
> > > > >>
> > >
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FType-Based-Property-Renaming&data=02%7C01%7Caharui%40adobe.com%7C8837468e7a2e4344564b08d7b6142ec7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178070124093456&sdata=0e5p3qrPLiRK1BZouGpU3Dnj70LI4VrhKNZs23R5eGM%3D&reserved=0
> > > > >> <
> > > > >>
> > >
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FType-Based-Property-Renaming&data=02%7C01%7Caharui%40adobe.com%7C8837468e7a2e4344564b08d7b6142ec7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178070124093456&sdata=0e5p3qrPLiRK1BZouGpU3Dnj70LI4VrhKNZs23R5eGM%3D&reserved=0
> > > > >> >
> > > > >>
> > > > >> The function seems to be
> goog.reflect.objectProperty()
> > > > >>
> > > > >> I’m not sure exactly how it works though.
> > > > >>
> > > > >> > On Jan 16, 2020, at 1:37 AM, Greg Dove <
> > greg.dove@gmail.com
> > > >
> > > wrote:
> > > > >> >
> > > > >> > actually just as another fyi, Harbs pointed out
> some
> > > intriguing
> > > goog
> > > > >> > methods recently - I don't have an immediate
> > reference to it
> > > sorry. One
> > > > >> of
> > > > >> > those seemed to allow for access to renamed
> names by
> > > wrapping the
> > > > >> original
> > > > >> > names in a 'magic' method that presumably GCC
> > recognises
> > > (but
> > > presumably
> > > > >> > returns the name unchanged in debug mode)
> > > > >> >
> > > > >> >
> > > > >> > On Thu, Jan 16, 2020 at 12:33 PM Greg Dove <
> > > greg.dove@gmail.com>
> > > wrote:
> > > > >> >
> > > > >> >> 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 <
> > > > >> joshtynjala@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%7C8837468e7a2e4344564b08d7b6142ec7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178070124093456&sdata=s2qIjF5F3fJcvnIWOBnTOKHG3FTo6i1xaUJ04%2FhgShY%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%7C8837468e7a2e4344564b08d7b6142ec7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178070124093456&sdata=pA01nbT%2BFHtnISBm9Fn1cq2HMR1jjrje9VWHKQfQ7vc%3D&reserved=0
> > > >
> > > > >> >>>
> > > > >> >>
> > > > >>
> > > > >>
> > > >
> > > >
> > > >
> > >
> > >
> > >
> >
> >
> >
>
>
>
--
Carlos Rovira
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C8837468e7a2e4344564b08d7b6142ec7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178070124093456&sdata=JCe1NkhbCbHDrfEYvIr2oBt6BKdeTIRL%2F66510k%2F%2F5Q%3D&reserved=0
Re: MXML and warn-public vars
Posted by Carlos Rovira <ca...@apache.org>.
Hi Alex,
I think this should transparent for the final user and not need to add a
compiler option, just configure all the strings that can cause problems,
since for what I understand the problem, we can know what strings are
problematic, right?
Thanks
El jue., 20 feb. 2020 a las 10:44, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> This change is breaking some modules when -rename-public-vars=false.
> Let's say the main app has some method "foo" that gets renamed. It might
> accidentally get a minified name that coincides with a public var in the
> module. For tour de flex, some API gets the minified name "UP". A module
> has code that references Keyboard.UP.
>
> In Pashmina's app, some API gets a minified name like "vs" and the module
> has a property "vs" (for a ViewStack).
>
> We try to allow renaming of APIs in modules for size savings. The list of
> renames in the main app is output to a file and read into the compiler when
> compiling the module so it starts with the same renaming map.
>
> One thought I had about solving this is to add another compiler option
> that allows a list of other names to not rename. So for the "UP" scenario,
> I would compile the main app with, say, -forbidden-minified-names=UP.
> Folks can probably work around the problem by using Keyboard.UP in the
> main app, but that bloats the main app. The compiler can already read a
> file of rename maps, so we could just use that, but I think a simpler
> command-line list will be more convenient.
>
> Thoughts?
> -Alex
>
> On 2/5/20, 12:18 PM, "Josh Tynjala" <jo...@bowlerhat.dev> wrote:
>
> Yeah, I'll make sure that users can control whether renaming happens
> or not.
>
> --
> Josh Tynjala
> Bowler Hat LLC <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C8dcbb865725d4151564408d7aa7893c9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637165307165113089&sdata=a5evE514IT0GdVvL7w5IbOCcnyb%2FCwCqgxhOIlJsFvM%3D&reserved=0
> >
>
>
> On Wed, Feb 5, 2020 at 11:51 AM Alex Harui <ah...@adobe.com.invalid>
> wrote:
>
> > Great work, Josh!
> >
> > I have to say that the objectProperty output was adding pain to
> debugging
> > so looking forward to that going away. I'm assuming there will be
> compiler
> > options/directives to control renaming? I think there are some
> scenarios
> > where it is safe to have public variables renamed.
> >
> > Thanks,
> > -Alex
> >
> > On 2/5/20, 11:44 AM, "Josh Tynjala" <jo...@bowlerhat.dev>
> wrote:
> >
> > Thank you for the tips, Alex. Much appreciated. With your help,
> I've
> > determined how to use Closure compiler's Java API to prevent the
> > renaming
> > of a specific public variable that has not been @export-ed. Now,
> I
> > should
> > be able to expand this prototype to a full version that prevents
> the
> > renaming of all public variables.
> >
> > --
> > Josh Tynjala
> > Bowler Hat LLC <
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C8dcbb865725d4151564408d7aa7893c9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637165307165113089&sdata=a5evE514IT0GdVvL7w5IbOCcnyb%2FCwCqgxhOIlJsFvM%3D&reserved=0
> > >
> >
> >
> > On Sun, Jan 19, 2020 at 4:58 PM Alex Harui
> <ah...@adobe.com.invalid>
> > wrote:
> >
> > > In response to your prior post, the reason I am saying it
> removes
> > control
> > > is because I didn't see any option to not have the compiler
> output
> > > goog.reflect.objectProperty and I'm not clear everyone will
> > want/need it.
> > >
> > > Regarding how to control Closure Compiler's renaming, the
> details
> > might be
> > > changing because I believe I saw that Google refactored the
> > renamer. At a
> > > high-level, you probably know most of this, but for other folks
> > reading,
> > > the Closure Compiler is a set of Java Classes that form a
> series of
> > > Compiler Passes. Each Pass takes information (sometimes
> source,
> > sometimes
> > > the AST, sometimes other information, and modifies the AST.
> IIRC, a
> > final
> > > pass generates the output. There might be more than one pass
> for
> > output.
> > >
> > > The renaming pass we currently use can output as well as
> accept a
> > file of
> > > rename mappings. I’m confident we can subclass or modify and
> > replace the
> > > renaming pass and feed it a set of mappings. If you look in
> the
> > > royale-compiler source, we've already done this for some other
> > passes.
> > > Look through the Closure compiler source for what happens to
> the
> > compiler
> > > options:
> > >
> > > --variable_map_input_file
> > > --property_map_input_file
> > >
> > > You can build examples/mxroyale/TourDeFlexModules which
> outputs these
> > > files to see what is in them.
> > >
> > >
> > > We should also see if we can agree on the scenarios and
> likelihood of
> > > property access "by name". I can quickly think of:
> > >
> > > A) MXML setting properties by reference (high usage)
> > > B) MXML setting properties by value (high usage)
> > > C) Serializers/Deserializers (moderate usage)
> > > D) [] bracket access by Literal (occasional usage)
> > > E) [] bracket access by String Variable (occasional usage)
> > > F) [] bracket access by Expression (infrequent usage)
> > >
> > > Exports can solve A. The compiler can easily detect D & E and
> > prevent
> > > renaming. For C, we "could" autogenerate exports for any
> classes
> > with
> > > [RemoteClass] metadata or autogenerate getter/setters.
> > >
> > > To me, the only difficult case is F and it will rarely happen.
> > Maybe we
> > > can detect those and warn on that.
> > >
> > > Of course, I could be wrong...
> > > -Alex
> > >
> > >
> > > On 1/17/20, 10:08 AM, "Josh Tynjala" <
> joshtynjala@bowlerhat.dev>
> > wrote:
> > >
> > > Comments inline.
> > >
> > > On Thursday, January 16, 2020, Alex Harui
> > <ah...@adobe.com.invalid>
> > > wrote:
> > > > Maybe we should start by agreeing on facts and then
> goals and
> > then
> > > discuss solutions.
> > >
> > > Yes, I think that's a good place to start.
> > >
> > > >
> > > > Here are some facts that come to mind, not a complete
> list.
> > > >
> > > > 1) An export does not prevent renaming. It builds an
> alias.
> > All
> > > references within the set of sources to be minified are
> renamed.
> > >
> > > Agreed.
> > >
> > > > 2) Closure's export mechanism only works on non-scalars
> > (Object,
> > > Arrays,
> > > Functions) and not Number, String, Boolean because
> non-scalars
> > are
> > > pass-by-reference instead of pass-by-value
> > >
> > > Agreed.
> > >
> > > > 3) The Closure Compiler is open source and designed to be
> > extended
> > >
> > > Agreed.
> > >
> > > > 4) Use of goog.reflect.objectProperty is not necessarily
> the
> > only
> > > way to
> > > control renaming. It is the way recommended by Google for
> those
> > who
> > > can't
> > > extend the compiler. We are not constrained to modify our
> output
> > > because
> > > we have control over the compiler.
> > >
> > > Could you share some details how we might have more
> control over
> > > Closure
> > > compiler's renaming? It sounds like you know, at least
> somewhat,
> > how
> > > to use
> > > its lower-level Java APIs, but you've never shared the
> details
> > when
> > > you've
> > > mentioned them in this thread or in the past.
> > >
> > > I should add that I've personally tried to research this
> topic
> > myself,
> > > but
> > > I had a very hard time finding any information that wasn't
> just
> > someone
> > > explaining to a JS developer that they needed to modify
> their JS
> > code.
> > > I
> > > eventually couldn't justify spending more time to keep
> looking.
> > >
> > > > 5) The compiler knows things about how properties were
> > accessed.
> > > That
> > > information is lost in the output in many cases.
> Therefore, it
> > should
> > > be
> > > better to inform the Google minifier directly from the
> Royale
> > compiler,
> > > instead of leaving hints in the output.
> > >
> > > Agreed. I'm personally not fully convinced that the Royale
> > compiler has
> > > enough information for dynamic stuff (like for
> serialization
> > with type
> > > Object), but that may be due to ignorance about Closure
> > compiler's
> > > capabilities. Even without knowing how it works, I can
> imagine
> > how it
> > > might
> > > be relatively easy to prevent renaming of public
> variables, but
> > the
> > > dynamic
> > > stuff is trickier. For the dynamic stuff, maybe it's just a
> > matter of
> > > Closure detecting when a variable is typed as Object, and
> then
> > it can
> > > switch to ["string"] syntax on its own (instead of us
> doing it
> > in the
> > > debug
> > > build, like with -js-dynamic-access-unknown-members).
> > >
> > > > 7) We are pretty close to allowing renaming across
> modules.
> > It was
> > > working for a while, but a scenario popped up that isn't
> > currently
> > > handled. We can pre-load the Closure renamer with a name
> map.
> > >
> > > I haven't looked in detail at the module implementation and
> > don't plan
> > > to,
> > > but I understand it well enough at a high level to say
> "agreed"
> > here
> > > too
> > >
> > > >
> > > > These are hypotheses, and not proven facts.
> > > > 8) The big gain from not exporting everything is in dead
> code
> > removal
> > > instead of shorter variable names
> > >
> > > Agreed, personally. It seems like others have expressed
> interest
> > in
> > > both,
> > > though. I hope that they'll be willing to prioriitze dead
> code
> > removal,
> > > since it will probably have the bigger impact (my own tests
> > removing
> > > @export have been promising in this regard).
> > >
> > > > 9) Renaming can complicate and slow
> > serialization/deserialization
> > >
> > > Agreed, and this is the harder portion to get working, I
> think.
> > >
> > > However, if release builds didn't rename public variables,
> and
> > also
> > > didn't
> > > rename dynamic accesses, that would remove my biggest
> > frustration with
> > > how
> > > ActionScript works in Royale/JS compared to SWF. If both
> kept
> > their
> > > original names, things that feel broken today would "just
> work"
> > again.
> > >
> > > >
> > > > IMO, we want to be heading in the direction of A)
> allowing
> > control
> > > over
> > > what gets renamed
> > >
> > > Agreed, but as I said before, I think that dead code
> removal
> > will have
> > > more
> > > impact than control over renaming, so if it's one or the
> other,
> > I'm
> > > okay
> > > with no control over renaming.
> > >
> > > > B) capturing information from the compiler,
> > > > C) controlling the set of renames and exports directly,
> not
> > through
> > > the
> > > output.
> > >
> > > Agreed, being able to pass information Closure compiler on
> the
> > Java
> > > side
> > > would be better. than through the JS output
> > >
> > >
> > > >
> > > > My 2 cents,
> > > > -Alex
> > > >
> > > >
> > > > On 1/16/20, 2:48 PM, "Josh Tynjala" <
> joshtynjala@bowlerhat.dev
> > >
> > > wrote:
> > > >
> > > > Some additional context, if anyone is interested.
> > > >
> > > > At the request of Harbs, I am currently
> investigating how
> > we
> > > might
> > > remove
> > > > @export from our generated JS code to improve the
> > minimization
> > > even
> > > more.
> > > > When I modified the compiler to skip emitting
> @export in
> > some
> > > places,
> > > a
> > > > release build of TourDeJewel was initially broken.
> When I
> > added
> > > > goog.reflect.objectProperty(), not only did it fix
> setting
> > public
> > > variables
> > > > in MXML, it also made that release build of
> TourDeJewel
> > start
> > > working
> > > again.
> > > >
> > > > --
> > > > Josh Tynjala
> > > > Bowler Hat LLC <
> > >
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C8dcbb865725d4151564408d7aa7893c9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637165307165113089&sdata=a5evE514IT0GdVvL7w5IbOCcnyb%2FCwCqgxhOIlJsFvM%3D&reserved=0
> > > >
> > > >
> > > >
> > > > On Thu, Jan 16, 2020 at 12:59 PM Josh Tynjala <
> > > joshtynjala@bowlerhat.dev>
> > > > wrote:
> > > >
> > > > > Thank you, Harbs! Wrapping the variable name in a
> > > > > goog.reflect.objectProperty() call works
> perfectly. This
> > is
> > > exactly
> > > why I
> > > > > started this thread, to see if anyone could suggest
> > possible
> > > alternatives.
> > > > >
> > > > > Thankfully, we can keep the same simple data
> structure as
> > > before,
> > > and my
> > > > > initial proposal with functions can be forgotten.
> In a
> > release
> > > build, I can
> > > > > see that goog.reflect.objectProperty() calls are
> > replaced by a
> > > simple
> > > > > string literal (containing the minified variable
> name),
> > so we
> > > don't
> > > have to
> > > > > worry about extra performance impact.
> > > > >
> > > > > --
> > > > > Josh Tynjala
> > > > > Bowler Hat LLC <
> > >
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C8dcbb865725d4151564408d7aa7893c9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637165307165113089&sdata=a5evE514IT0GdVvL7w5IbOCcnyb%2FCwCqgxhOIlJsFvM%3D&reserved=0
> > > >
> > > > >
> > > > >
> > > > > On Wed, Jan 15, 2020 at 8:32 PM Harbs <
> > harbs.lists@gmail.com>
> > > wrote:
> > > > >
> > > > >> Sounds good!
> > > > >>
> > > > >>
> > > > >>
> > >
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FType-Based-Property-Renaming&data=02%7C01%7Caharui%40adobe.com%7C8dcbb865725d4151564408d7aa7893c9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637165307165113089&sdata=O5PMzmZaDJnnWfkJL1EQMlGudNjREP88VIbImidkXtw%3D&reserved=0
> > > > >> <
> > > > >>
> > >
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FType-Based-Property-Renaming&data=02%7C01%7Caharui%40adobe.com%7C8dcbb865725d4151564408d7aa7893c9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637165307165113089&sdata=O5PMzmZaDJnnWfkJL1EQMlGudNjREP88VIbImidkXtw%3D&reserved=0
> > > > >> >
> > > > >>
> > > > >> The function seems to be
> goog.reflect.objectProperty()
> > > > >>
> > > > >> I’m not sure exactly how it works though.
> > > > >>
> > > > >> > On Jan 16, 2020, at 1:37 AM, Greg Dove <
> > greg.dove@gmail.com
> > > >
> > > wrote:
> > > > >> >
> > > > >> > actually just as another fyi, Harbs pointed out
> some
> > > intriguing
> > > goog
> > > > >> > methods recently - I don't have an immediate
> > reference to it
> > > sorry. One
> > > > >> of
> > > > >> > those seemed to allow for access to renamed
> names by
> > > wrapping the
> > > > >> original
> > > > >> > names in a 'magic' method that presumably GCC
> > recognises
> > > (but
> > > presumably
> > > > >> > returns the name unchanged in debug mode)
> > > > >> >
> > > > >> >
> > > > >> > On Thu, Jan 16, 2020 at 12:33 PM Greg Dove <
> > > greg.dove@gmail.com>
> > > wrote:
> > > > >> >
> > > > >> >> 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 <
> > > > >> joshtynjala@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%7C8dcbb865725d4151564408d7aa7893c9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637165307165113089&sdata=M%2BEvAma5g8ufQL0Nf2Krb3hrr2ERTHhdsofqVUhm7f4%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%7C8dcbb865725d4151564408d7aa7893c9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637165307165113089&sdata=a5evE514IT0GdVvL7w5IbOCcnyb%2FCwCqgxhOIlJsFvM%3D&reserved=0
> > > >
> > > > >> >>>
> > > > >> >>
> > > > >>
> > > > >>
> > > >
> > > >
> > > >
> > >
> > >
> > >
> >
> >
> >
>
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: MXML and warn-public vars
Posted by Alex Harui <ah...@adobe.com.INVALID>.
This change is breaking some modules when -rename-public-vars=false. Let's say the main app has some method "foo" that gets renamed. It might accidentally get a minified name that coincides with a public var in the module. For tour de flex, some API gets the minified name "UP". A module has code that references Keyboard.UP.
In Pashmina's app, some API gets a minified name like "vs" and the module has a property "vs" (for a ViewStack).
We try to allow renaming of APIs in modules for size savings. The list of renames in the main app is output to a file and read into the compiler when compiling the module so it starts with the same renaming map.
One thought I had about solving this is to add another compiler option that allows a list of other names to not rename. So for the "UP" scenario, I would compile the main app with, say, -forbidden-minified-names=UP. Folks can probably work around the problem by using Keyboard.UP in the main app, but that bloats the main app. The compiler can already read a file of rename maps, so we could just use that, but I think a simpler command-line list will be more convenient.
Thoughts?
-Alex
On 2/5/20, 12:18 PM, "Josh Tynjala" <jo...@bowlerhat.dev> wrote:
Yeah, I'll make sure that users can control whether renaming happens or not.
--
Josh Tynjala
Bowler Hat LLC <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C8dcbb865725d4151564408d7aa7893c9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637165307165113089&sdata=a5evE514IT0GdVvL7w5IbOCcnyb%2FCwCqgxhOIlJsFvM%3D&reserved=0>
On Wed, Feb 5, 2020 at 11:51 AM Alex Harui <ah...@adobe.com.invalid> wrote:
> Great work, Josh!
>
> I have to say that the objectProperty output was adding pain to debugging
> so looking forward to that going away. I'm assuming there will be compiler
> options/directives to control renaming? I think there are some scenarios
> where it is safe to have public variables renamed.
>
> Thanks,
> -Alex
>
> On 2/5/20, 11:44 AM, "Josh Tynjala" <jo...@bowlerhat.dev> wrote:
>
> Thank you for the tips, Alex. Much appreciated. With your help, I've
> determined how to use Closure compiler's Java API to prevent the
> renaming
> of a specific public variable that has not been @export-ed. Now, I
> should
> be able to expand this prototype to a full version that prevents the
> renaming of all public variables.
>
> --
> Josh Tynjala
> Bowler Hat LLC <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C8dcbb865725d4151564408d7aa7893c9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637165307165113089&sdata=a5evE514IT0GdVvL7w5IbOCcnyb%2FCwCqgxhOIlJsFvM%3D&reserved=0
> >
>
>
> On Sun, Jan 19, 2020 at 4:58 PM Alex Harui <ah...@adobe.com.invalid>
> wrote:
>
> > In response to your prior post, the reason I am saying it removes
> control
> > is because I didn't see any option to not have the compiler output
> > goog.reflect.objectProperty and I'm not clear everyone will
> want/need it.
> >
> > Regarding how to control Closure Compiler's renaming, the details
> might be
> > changing because I believe I saw that Google refactored the
> renamer. At a
> > high-level, you probably know most of this, but for other folks
> reading,
> > the Closure Compiler is a set of Java Classes that form a series of
> > Compiler Passes. Each Pass takes information (sometimes source,
> sometimes
> > the AST, sometimes other information, and modifies the AST. IIRC, a
> final
> > pass generates the output. There might be more than one pass for
> output.
> >
> > The renaming pass we currently use can output as well as accept a
> file of
> > rename mappings. I’m confident we can subclass or modify and
> replace the
> > renaming pass and feed it a set of mappings. If you look in the
> > royale-compiler source, we've already done this for some other
> passes.
> > Look through the Closure compiler source for what happens to the
> compiler
> > options:
> >
> > --variable_map_input_file
> > --property_map_input_file
> >
> > You can build examples/mxroyale/TourDeFlexModules which outputs these
> > files to see what is in them.
> >
> >
> > We should also see if we can agree on the scenarios and likelihood of
> > property access "by name". I can quickly think of:
> >
> > A) MXML setting properties by reference (high usage)
> > B) MXML setting properties by value (high usage)
> > C) Serializers/Deserializers (moderate usage)
> > D) [] bracket access by Literal (occasional usage)
> > E) [] bracket access by String Variable (occasional usage)
> > F) [] bracket access by Expression (infrequent usage)
> >
> > Exports can solve A. The compiler can easily detect D & E and
> prevent
> > renaming. For C, we "could" autogenerate exports for any classes
> with
> > [RemoteClass] metadata or autogenerate getter/setters.
> >
> > To me, the only difficult case is F and it will rarely happen.
> Maybe we
> > can detect those and warn on that.
> >
> > Of course, I could be wrong...
> > -Alex
> >
> >
> > On 1/17/20, 10:08 AM, "Josh Tynjala" <jo...@bowlerhat.dev>
> wrote:
> >
> > Comments inline.
> >
> > On Thursday, January 16, 2020, Alex Harui
> <ah...@adobe.com.invalid>
> > wrote:
> > > Maybe we should start by agreeing on facts and then goals and
> then
> > discuss solutions.
> >
> > Yes, I think that's a good place to start.
> >
> > >
> > > Here are some facts that come to mind, not a complete list.
> > >
> > > 1) An export does not prevent renaming. It builds an alias.
> All
> > references within the set of sources to be minified are renamed.
> >
> > Agreed.
> >
> > > 2) Closure's export mechanism only works on non-scalars
> (Object,
> > Arrays,
> > Functions) and not Number, String, Boolean because non-scalars
> are
> > pass-by-reference instead of pass-by-value
> >
> > Agreed.
> >
> > > 3) The Closure Compiler is open source and designed to be
> extended
> >
> > Agreed.
> >
> > > 4) Use of goog.reflect.objectProperty is not necessarily the
> only
> > way to
> > control renaming. It is the way recommended by Google for those
> who
> > can't
> > extend the compiler. We are not constrained to modify our output
> > because
> > we have control over the compiler.
> >
> > Could you share some details how we might have more control over
> > Closure
> > compiler's renaming? It sounds like you know, at least somewhat,
> how
> > to use
> > its lower-level Java APIs, but you've never shared the details
> when
> > you've
> > mentioned them in this thread or in the past.
> >
> > I should add that I've personally tried to research this topic
> myself,
> > but
> > I had a very hard time finding any information that wasn't just
> someone
> > explaining to a JS developer that they needed to modify their JS
> code.
> > I
> > eventually couldn't justify spending more time to keep looking.
> >
> > > 5) The compiler knows things about how properties were
> accessed.
> > That
> > information is lost in the output in many cases. Therefore, it
> should
> > be
> > better to inform the Google minifier directly from the Royale
> compiler,
> > instead of leaving hints in the output.
> >
> > Agreed. I'm personally not fully convinced that the Royale
> compiler has
> > enough information for dynamic stuff (like for serialization
> with type
> > Object), but that may be due to ignorance about Closure
> compiler's
> > capabilities. Even without knowing how it works, I can imagine
> how it
> > might
> > be relatively easy to prevent renaming of public variables, but
> the
> > dynamic
> > stuff is trickier. For the dynamic stuff, maybe it's just a
> matter of
> > Closure detecting when a variable is typed as Object, and then
> it can
> > switch to ["string"] syntax on its own (instead of us doing it
> in the
> > debug
> > build, like with -js-dynamic-access-unknown-members).
> >
> > > 7) We are pretty close to allowing renaming across modules.
> It was
> > working for a while, but a scenario popped up that isn't
> currently
> > handled. We can pre-load the Closure renamer with a name map.
> >
> > I haven't looked in detail at the module implementation and
> don't plan
> > to,
> > but I understand it well enough at a high level to say "agreed"
> here
> > too
> >
> > >
> > > These are hypotheses, and not proven facts.
> > > 8) The big gain from not exporting everything is in dead code
> removal
> > instead of shorter variable names
> >
> > Agreed, personally. It seems like others have expressed interest
> in
> > both,
> > though. I hope that they'll be willing to prioriitze dead code
> removal,
> > since it will probably have the bigger impact (my own tests
> removing
> > @export have been promising in this regard).
> >
> > > 9) Renaming can complicate and slow
> serialization/deserialization
> >
> > Agreed, and this is the harder portion to get working, I think.
> >
> > However, if release builds didn't rename public variables, and
> also
> > didn't
> > rename dynamic accesses, that would remove my biggest
> frustration with
> > how
> > ActionScript works in Royale/JS compared to SWF. If both kept
> their
> > original names, things that feel broken today would "just work"
> again.
> >
> > >
> > > IMO, we want to be heading in the direction of A) allowing
> control
> > over
> > what gets renamed
> >
> > Agreed, but as I said before, I think that dead code removal
> will have
> > more
> > impact than control over renaming, so if it's one or the other,
> I'm
> > okay
> > with no control over renaming.
> >
> > > B) capturing information from the compiler,
> > > C) controlling the set of renames and exports directly, not
> through
> > the
> > output.
> >
> > Agreed, being able to pass information Closure compiler on the
> Java
> > side
> > would be better. than through the JS output
> >
> >
> > >
> > > My 2 cents,
> > > -Alex
> > >
> > >
> > > On 1/16/20, 2:48 PM, "Josh Tynjala" <joshtynjala@bowlerhat.dev
> >
> > wrote:
> > >
> > > Some additional context, if anyone is interested.
> > >
> > > At the request of Harbs, I am currently investigating how
> we
> > might
> > remove
> > > @export from our generated JS code to improve the
> minimization
> > even
> > more.
> > > When I modified the compiler to skip emitting @export in
> some
> > places,
> > a
> > > release build of TourDeJewel was initially broken. When I
> added
> > > goog.reflect.objectProperty(), not only did it fix setting
> public
> > variables
> > > in MXML, it also made that release build of TourDeJewel
> start
> > working
> > again.
> > >
> > > --
> > > Josh Tynjala
> > > Bowler Hat LLC <
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C8dcbb865725d4151564408d7aa7893c9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637165307165113089&sdata=a5evE514IT0GdVvL7w5IbOCcnyb%2FCwCqgxhOIlJsFvM%3D&reserved=0
> > >
> > >
> > >
> > > On Thu, Jan 16, 2020 at 12:59 PM Josh Tynjala <
> > joshtynjala@bowlerhat.dev>
> > > wrote:
> > >
> > > > Thank you, Harbs! Wrapping the variable name in a
> > > > goog.reflect.objectProperty() call works perfectly. This
> is
> > exactly
> > why I
> > > > started this thread, to see if anyone could suggest
> possible
> > alternatives.
> > > >
> > > > Thankfully, we can keep the same simple data structure as
> > before,
> > and my
> > > > initial proposal with functions can be forgotten. In a
> release
> > build, I can
> > > > see that goog.reflect.objectProperty() calls are
> replaced by a
> > simple
> > > > string literal (containing the minified variable name),
> so we
> > don't
> > have to
> > > > worry about extra performance impact.
> > > >
> > > > --
> > > > Josh Tynjala
> > > > Bowler Hat LLC <
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C8dcbb865725d4151564408d7aa7893c9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637165307165113089&sdata=a5evE514IT0GdVvL7w5IbOCcnyb%2FCwCqgxhOIlJsFvM%3D&reserved=0
> > >
> > > >
> > > >
> > > > On Wed, Jan 15, 2020 at 8:32 PM Harbs <
> harbs.lists@gmail.com>
> > wrote:
> > > >
> > > >> Sounds good!
> > > >>
> > > >>
> > > >>
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FType-Based-Property-Renaming&data=02%7C01%7Caharui%40adobe.com%7C8dcbb865725d4151564408d7aa7893c9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637165307165113089&sdata=O5PMzmZaDJnnWfkJL1EQMlGudNjREP88VIbImidkXtw%3D&reserved=0
> > > >> <
> > > >>
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FType-Based-Property-Renaming&data=02%7C01%7Caharui%40adobe.com%7C8dcbb865725d4151564408d7aa7893c9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637165307165113089&sdata=O5PMzmZaDJnnWfkJL1EQMlGudNjREP88VIbImidkXtw%3D&reserved=0
> > > >> >
> > > >>
> > > >> The function seems to be goog.reflect.objectProperty()
> > > >>
> > > >> I’m not sure exactly how it works though.
> > > >>
> > > >> > On Jan 16, 2020, at 1:37 AM, Greg Dove <
> greg.dove@gmail.com
> > >
> > wrote:
> > > >> >
> > > >> > actually just as another fyi, Harbs pointed out some
> > intriguing
> > goog
> > > >> > methods recently - I don't have an immediate
> reference to it
> > sorry. One
> > > >> of
> > > >> > those seemed to allow for access to renamed names by
> > wrapping the
> > > >> original
> > > >> > names in a 'magic' method that presumably GCC
> recognises
> > (but
> > presumably
> > > >> > returns the name unchanged in debug mode)
> > > >> >
> > > >> >
> > > >> > On Thu, Jan 16, 2020 at 12:33 PM Greg Dove <
> > greg.dove@gmail.com>
> > wrote:
> > > >> >
> > > >> >> 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 <
> > > >> joshtynjala@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%7C8dcbb865725d4151564408d7aa7893c9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637165307165113089&sdata=M%2BEvAma5g8ufQL0Nf2Krb3hrr2ERTHhdsofqVUhm7f4%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%7C8dcbb865725d4151564408d7aa7893c9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637165307165113089&sdata=a5evE514IT0GdVvL7w5IbOCcnyb%2FCwCqgxhOIlJsFvM%3D&reserved=0
> > >
> > > >> >>>
> > > >> >>
> > > >>
> > > >>
> > >
> > >
> > >
> >
> >
> >
>
>
>
Re: MXML and warn-public vars
Posted by Josh Tynjala <jo...@bowlerhat.dev>.
Yeah, I'll make sure that users can control whether renaming happens or not.
--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>
On Wed, Feb 5, 2020 at 11:51 AM Alex Harui <ah...@adobe.com.invalid> wrote:
> Great work, Josh!
>
> I have to say that the objectProperty output was adding pain to debugging
> so looking forward to that going away. I'm assuming there will be compiler
> options/directives to control renaming? I think there are some scenarios
> where it is safe to have public variables renamed.
>
> Thanks,
> -Alex
>
> On 2/5/20, 11:44 AM, "Josh Tynjala" <jo...@bowlerhat.dev> wrote:
>
> Thank you for the tips, Alex. Much appreciated. With your help, I've
> determined how to use Closure compiler's Java API to prevent the
> renaming
> of a specific public variable that has not been @export-ed. Now, I
> should
> be able to expand this prototype to a full version that prevents the
> renaming of all public variables.
>
> --
> Josh Tynjala
> Bowler Hat LLC <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7Cb7700e87eb404fce199308d7aa7368fb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637165286896410173&sdata=lMDPEZBrk7kzWKr5MobPjR7R%2F1gFsWNJxoEJptTQxqA%3D&reserved=0
> >
>
>
> On Sun, Jan 19, 2020 at 4:58 PM Alex Harui <ah...@adobe.com.invalid>
> wrote:
>
> > In response to your prior post, the reason I am saying it removes
> control
> > is because I didn't see any option to not have the compiler output
> > goog.reflect.objectProperty and I'm not clear everyone will
> want/need it.
> >
> > Regarding how to control Closure Compiler's renaming, the details
> might be
> > changing because I believe I saw that Google refactored the
> renamer. At a
> > high-level, you probably know most of this, but for other folks
> reading,
> > the Closure Compiler is a set of Java Classes that form a series of
> > Compiler Passes. Each Pass takes information (sometimes source,
> sometimes
> > the AST, sometimes other information, and modifies the AST. IIRC, a
> final
> > pass generates the output. There might be more than one pass for
> output.
> >
> > The renaming pass we currently use can output as well as accept a
> file of
> > rename mappings. I’m confident we can subclass or modify and
> replace the
> > renaming pass and feed it a set of mappings. If you look in the
> > royale-compiler source, we've already done this for some other
> passes.
> > Look through the Closure compiler source for what happens to the
> compiler
> > options:
> >
> > --variable_map_input_file
> > --property_map_input_file
> >
> > You can build examples/mxroyale/TourDeFlexModules which outputs these
> > files to see what is in them.
> >
> >
> > We should also see if we can agree on the scenarios and likelihood of
> > property access "by name". I can quickly think of:
> >
> > A) MXML setting properties by reference (high usage)
> > B) MXML setting properties by value (high usage)
> > C) Serializers/Deserializers (moderate usage)
> > D) [] bracket access by Literal (occasional usage)
> > E) [] bracket access by String Variable (occasional usage)
> > F) [] bracket access by Expression (infrequent usage)
> >
> > Exports can solve A. The compiler can easily detect D & E and
> prevent
> > renaming. For C, we "could" autogenerate exports for any classes
> with
> > [RemoteClass] metadata or autogenerate getter/setters.
> >
> > To me, the only difficult case is F and it will rarely happen.
> Maybe we
> > can detect those and warn on that.
> >
> > Of course, I could be wrong...
> > -Alex
> >
> >
> > On 1/17/20, 10:08 AM, "Josh Tynjala" <jo...@bowlerhat.dev>
> wrote:
> >
> > Comments inline.
> >
> > On Thursday, January 16, 2020, Alex Harui
> <ah...@adobe.com.invalid>
> > wrote:
> > > Maybe we should start by agreeing on facts and then goals and
> then
> > discuss solutions.
> >
> > Yes, I think that's a good place to start.
> >
> > >
> > > Here are some facts that come to mind, not a complete list.
> > >
> > > 1) An export does not prevent renaming. It builds an alias.
> All
> > references within the set of sources to be minified are renamed.
> >
> > Agreed.
> >
> > > 2) Closure's export mechanism only works on non-scalars
> (Object,
> > Arrays,
> > Functions) and not Number, String, Boolean because non-scalars
> are
> > pass-by-reference instead of pass-by-value
> >
> > Agreed.
> >
> > > 3) The Closure Compiler is open source and designed to be
> extended
> >
> > Agreed.
> >
> > > 4) Use of goog.reflect.objectProperty is not necessarily the
> only
> > way to
> > control renaming. It is the way recommended by Google for those
> who
> > can't
> > extend the compiler. We are not constrained to modify our output
> > because
> > we have control over the compiler.
> >
> > Could you share some details how we might have more control over
> > Closure
> > compiler's renaming? It sounds like you know, at least somewhat,
> how
> > to use
> > its lower-level Java APIs, but you've never shared the details
> when
> > you've
> > mentioned them in this thread or in the past.
> >
> > I should add that I've personally tried to research this topic
> myself,
> > but
> > I had a very hard time finding any information that wasn't just
> someone
> > explaining to a JS developer that they needed to modify their JS
> code.
> > I
> > eventually couldn't justify spending more time to keep looking.
> >
> > > 5) The compiler knows things about how properties were
> accessed.
> > That
> > information is lost in the output in many cases. Therefore, it
> should
> > be
> > better to inform the Google minifier directly from the Royale
> compiler,
> > instead of leaving hints in the output.
> >
> > Agreed. I'm personally not fully convinced that the Royale
> compiler has
> > enough information for dynamic stuff (like for serialization
> with type
> > Object), but that may be due to ignorance about Closure
> compiler's
> > capabilities. Even without knowing how it works, I can imagine
> how it
> > might
> > be relatively easy to prevent renaming of public variables, but
> the
> > dynamic
> > stuff is trickier. For the dynamic stuff, maybe it's just a
> matter of
> > Closure detecting when a variable is typed as Object, and then
> it can
> > switch to ["string"] syntax on its own (instead of us doing it
> in the
> > debug
> > build, like with -js-dynamic-access-unknown-members).
> >
> > > 7) We are pretty close to allowing renaming across modules.
> It was
> > working for a while, but a scenario popped up that isn't
> currently
> > handled. We can pre-load the Closure renamer with a name map.
> >
> > I haven't looked in detail at the module implementation and
> don't plan
> > to,
> > but I understand it well enough at a high level to say "agreed"
> here
> > too
> >
> > >
> > > These are hypotheses, and not proven facts.
> > > 8) The big gain from not exporting everything is in dead code
> removal
> > instead of shorter variable names
> >
> > Agreed, personally. It seems like others have expressed interest
> in
> > both,
> > though. I hope that they'll be willing to prioriitze dead code
> removal,
> > since it will probably have the bigger impact (my own tests
> removing
> > @export have been promising in this regard).
> >
> > > 9) Renaming can complicate and slow
> serialization/deserialization
> >
> > Agreed, and this is the harder portion to get working, I think.
> >
> > However, if release builds didn't rename public variables, and
> also
> > didn't
> > rename dynamic accesses, that would remove my biggest
> frustration with
> > how
> > ActionScript works in Royale/JS compared to SWF. If both kept
> their
> > original names, things that feel broken today would "just work"
> again.
> >
> > >
> > > IMO, we want to be heading in the direction of A) allowing
> control
> > over
> > what gets renamed
> >
> > Agreed, but as I said before, I think that dead code removal
> will have
> > more
> > impact than control over renaming, so if it's one or the other,
> I'm
> > okay
> > with no control over renaming.
> >
> > > B) capturing information from the compiler,
> > > C) controlling the set of renames and exports directly, not
> through
> > the
> > output.
> >
> > Agreed, being able to pass information Closure compiler on the
> Java
> > side
> > would be better. than through the JS output
> >
> >
> > >
> > > My 2 cents,
> > > -Alex
> > >
> > >
> > > On 1/16/20, 2:48 PM, "Josh Tynjala" <joshtynjala@bowlerhat.dev
> >
> > wrote:
> > >
> > > Some additional context, if anyone is interested.
> > >
> > > At the request of Harbs, I am currently investigating how
> we
> > might
> > remove
> > > @export from our generated JS code to improve the
> minimization
> > even
> > more.
> > > When I modified the compiler to skip emitting @export in
> some
> > places,
> > a
> > > release build of TourDeJewel was initially broken. When I
> added
> > > goog.reflect.objectProperty(), not only did it fix setting
> public
> > variables
> > > in MXML, it also made that release build of TourDeJewel
> start
> > working
> > again.
> > >
> > > --
> > > Josh Tynjala
> > > Bowler Hat LLC <
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7Cb7700e87eb404fce199308d7aa7368fb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637165286896410173&sdata=lMDPEZBrk7kzWKr5MobPjR7R%2F1gFsWNJxoEJptTQxqA%3D&reserved=0
> > >
> > >
> > >
> > > On Thu, Jan 16, 2020 at 12:59 PM Josh Tynjala <
> > joshtynjala@bowlerhat.dev>
> > > wrote:
> > >
> > > > Thank you, Harbs! Wrapping the variable name in a
> > > > goog.reflect.objectProperty() call works perfectly. This
> is
> > exactly
> > why I
> > > > started this thread, to see if anyone could suggest
> possible
> > alternatives.
> > > >
> > > > Thankfully, we can keep the same simple data structure as
> > before,
> > and my
> > > > initial proposal with functions can be forgotten. In a
> release
> > build, I can
> > > > see that goog.reflect.objectProperty() calls are
> replaced by a
> > simple
> > > > string literal (containing the minified variable name),
> so we
> > don't
> > have to
> > > > worry about extra performance impact.
> > > >
> > > > --
> > > > Josh Tynjala
> > > > Bowler Hat LLC <
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7Cb7700e87eb404fce199308d7aa7368fb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637165286896410173&sdata=lMDPEZBrk7kzWKr5MobPjR7R%2F1gFsWNJxoEJptTQxqA%3D&reserved=0
> > >
> > > >
> > > >
> > > > On Wed, Jan 15, 2020 at 8:32 PM Harbs <
> harbs.lists@gmail.com>
> > wrote:
> > > >
> > > >> Sounds good!
> > > >>
> > > >>
> > > >>
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FType-Based-Property-Renaming&data=02%7C01%7Caharui%40adobe.com%7Cb7700e87eb404fce199308d7aa7368fb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637165286896410173&sdata=xbvdLH%2FKesfH%2BXLc8AIOdsUsoeS%2BF6hMBiVV3fDXHIc%3D&reserved=0
> > > >> <
> > > >>
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FType-Based-Property-Renaming&data=02%7C01%7Caharui%40adobe.com%7Cb7700e87eb404fce199308d7aa7368fb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637165286896410173&sdata=xbvdLH%2FKesfH%2BXLc8AIOdsUsoeS%2BF6hMBiVV3fDXHIc%3D&reserved=0
> > > >> >
> > > >>
> > > >> The function seems to be goog.reflect.objectProperty()
> > > >>
> > > >> I’m not sure exactly how it works though.
> > > >>
> > > >> > On Jan 16, 2020, at 1:37 AM, Greg Dove <
> greg.dove@gmail.com
> > >
> > wrote:
> > > >> >
> > > >> > actually just as another fyi, Harbs pointed out some
> > intriguing
> > goog
> > > >> > methods recently - I don't have an immediate
> reference to it
> > sorry. One
> > > >> of
> > > >> > those seemed to allow for access to renamed names by
> > wrapping the
> > > >> original
> > > >> > names in a 'magic' method that presumably GCC
> recognises
> > (but
> > presumably
> > > >> > returns the name unchanged in debug mode)
> > > >> >
> > > >> >
> > > >> > On Thu, Jan 16, 2020 at 12:33 PM Greg Dove <
> > greg.dove@gmail.com>
> > wrote:
> > > >> >
> > > >> >> 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 <
> > > >> joshtynjala@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%7Cb7700e87eb404fce199308d7aa7368fb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637165286896410173&sdata=Mr4EdF%2Bm%2B3T%2BAskoYeXXlle5PnSgON%2B5jgPC%2F0Zxr0w%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%7Cb7700e87eb404fce199308d7aa7368fb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637165286896410173&sdata=lMDPEZBrk7kzWKr5MobPjR7R%2F1gFsWNJxoEJptTQxqA%3D&reserved=0
> > >
> > > >> >>>
> > > >> >>
> > > >>
> > > >>
> > >
> > >
> > >
> >
> >
> >
>
>
>
Re: MXML and warn-public vars
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Great work, Josh!
I have to say that the objectProperty output was adding pain to debugging so looking forward to that going away. I'm assuming there will be compiler options/directives to control renaming? I think there are some scenarios where it is safe to have public variables renamed.
Thanks,
-Alex
On 2/5/20, 11:44 AM, "Josh Tynjala" <jo...@bowlerhat.dev> wrote:
Thank you for the tips, Alex. Much appreciated. With your help, I've
determined how to use Closure compiler's Java API to prevent the renaming
of a specific public variable that has not been @export-ed. Now, I should
be able to expand this prototype to a full version that prevents the
renaming of all public variables.
--
Josh Tynjala
Bowler Hat LLC <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7Cb7700e87eb404fce199308d7aa7368fb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637165286896410173&sdata=lMDPEZBrk7kzWKr5MobPjR7R%2F1gFsWNJxoEJptTQxqA%3D&reserved=0>
On Sun, Jan 19, 2020 at 4:58 PM Alex Harui <ah...@adobe.com.invalid> wrote:
> In response to your prior post, the reason I am saying it removes control
> is because I didn't see any option to not have the compiler output
> goog.reflect.objectProperty and I'm not clear everyone will want/need it.
>
> Regarding how to control Closure Compiler's renaming, the details might be
> changing because I believe I saw that Google refactored the renamer. At a
> high-level, you probably know most of this, but for other folks reading,
> the Closure Compiler is a set of Java Classes that form a series of
> Compiler Passes. Each Pass takes information (sometimes source, sometimes
> the AST, sometimes other information, and modifies the AST. IIRC, a final
> pass generates the output. There might be more than one pass for output.
>
> The renaming pass we currently use can output as well as accept a file of
> rename mappings. I’m confident we can subclass or modify and replace the
> renaming pass and feed it a set of mappings. If you look in the
> royale-compiler source, we've already done this for some other passes.
> Look through the Closure compiler source for what happens to the compiler
> options:
>
> --variable_map_input_file
> --property_map_input_file
>
> You can build examples/mxroyale/TourDeFlexModules which outputs these
> files to see what is in them.
>
>
> We should also see if we can agree on the scenarios and likelihood of
> property access "by name". I can quickly think of:
>
> A) MXML setting properties by reference (high usage)
> B) MXML setting properties by value (high usage)
> C) Serializers/Deserializers (moderate usage)
> D) [] bracket access by Literal (occasional usage)
> E) [] bracket access by String Variable (occasional usage)
> F) [] bracket access by Expression (infrequent usage)
>
> Exports can solve A. The compiler can easily detect D & E and prevent
> renaming. For C, we "could" autogenerate exports for any classes with
> [RemoteClass] metadata or autogenerate getter/setters.
>
> To me, the only difficult case is F and it will rarely happen. Maybe we
> can detect those and warn on that.
>
> Of course, I could be wrong...
> -Alex
>
>
> On 1/17/20, 10:08 AM, "Josh Tynjala" <jo...@bowlerhat.dev> wrote:
>
> Comments inline.
>
> On Thursday, January 16, 2020, Alex Harui <ah...@adobe.com.invalid>
> wrote:
> > Maybe we should start by agreeing on facts and then goals and then
> discuss solutions.
>
> Yes, I think that's a good place to start.
>
> >
> > Here are some facts that come to mind, not a complete list.
> >
> > 1) An export does not prevent renaming. It builds an alias. All
> references within the set of sources to be minified are renamed.
>
> Agreed.
>
> > 2) Closure's export mechanism only works on non-scalars (Object,
> Arrays,
> Functions) and not Number, String, Boolean because non-scalars are
> pass-by-reference instead of pass-by-value
>
> Agreed.
>
> > 3) The Closure Compiler is open source and designed to be extended
>
> Agreed.
>
> > 4) Use of goog.reflect.objectProperty is not necessarily the only
> way to
> control renaming. It is the way recommended by Google for those who
> can't
> extend the compiler. We are not constrained to modify our output
> because
> we have control over the compiler.
>
> Could you share some details how we might have more control over
> Closure
> compiler's renaming? It sounds like you know, at least somewhat, how
> to use
> its lower-level Java APIs, but you've never shared the details when
> you've
> mentioned them in this thread or in the past.
>
> I should add that I've personally tried to research this topic myself,
> but
> I had a very hard time finding any information that wasn't just someone
> explaining to a JS developer that they needed to modify their JS code.
> I
> eventually couldn't justify spending more time to keep looking.
>
> > 5) The compiler knows things about how properties were accessed.
> That
> information is lost in the output in many cases. Therefore, it should
> be
> better to inform the Google minifier directly from the Royale compiler,
> instead of leaving hints in the output.
>
> Agreed. I'm personally not fully convinced that the Royale compiler has
> enough information for dynamic stuff (like for serialization with type
> Object), but that may be due to ignorance about Closure compiler's
> capabilities. Even without knowing how it works, I can imagine how it
> might
> be relatively easy to prevent renaming of public variables, but the
> dynamic
> stuff is trickier. For the dynamic stuff, maybe it's just a matter of
> Closure detecting when a variable is typed as Object, and then it can
> switch to ["string"] syntax on its own (instead of us doing it in the
> debug
> build, like with -js-dynamic-access-unknown-members).
>
> > 7) We are pretty close to allowing renaming across modules. It was
> working for a while, but a scenario popped up that isn't currently
> handled. We can pre-load the Closure renamer with a name map.
>
> I haven't looked in detail at the module implementation and don't plan
> to,
> but I understand it well enough at a high level to say "agreed" here
> too
>
> >
> > These are hypotheses, and not proven facts.
> > 8) The big gain from not exporting everything is in dead code removal
> instead of shorter variable names
>
> Agreed, personally. It seems like others have expressed interest in
> both,
> though. I hope that they'll be willing to prioriitze dead code removal,
> since it will probably have the bigger impact (my own tests removing
> @export have been promising in this regard).
>
> > 9) Renaming can complicate and slow serialization/deserialization
>
> Agreed, and this is the harder portion to get working, I think.
>
> However, if release builds didn't rename public variables, and also
> didn't
> rename dynamic accesses, that would remove my biggest frustration with
> how
> ActionScript works in Royale/JS compared to SWF. If both kept their
> original names, things that feel broken today would "just work" again.
>
> >
> > IMO, we want to be heading in the direction of A) allowing control
> over
> what gets renamed
>
> Agreed, but as I said before, I think that dead code removal will have
> more
> impact than control over renaming, so if it's one or the other, I'm
> okay
> with no control over renaming.
>
> > B) capturing information from the compiler,
> > C) controlling the set of renames and exports directly, not through
> the
> output.
>
> Agreed, being able to pass information Closure compiler on the Java
> side
> would be better. than through the JS output
>
>
> >
> > My 2 cents,
> > -Alex
> >
> >
> > On 1/16/20, 2:48 PM, "Josh Tynjala" <jo...@bowlerhat.dev>
> wrote:
> >
> > Some additional context, if anyone is interested.
> >
> > At the request of Harbs, I am currently investigating how we
> might
> remove
> > @export from our generated JS code to improve the minimization
> even
> more.
> > When I modified the compiler to skip emitting @export in some
> places,
> a
> > release build of TourDeJewel was initially broken. When I added
> > goog.reflect.objectProperty(), not only did it fix setting public
> variables
> > in MXML, it also made that release build of TourDeJewel start
> working
> again.
> >
> > --
> > Josh Tynjala
> > Bowler Hat LLC <
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7Cb7700e87eb404fce199308d7aa7368fb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637165286896410173&sdata=lMDPEZBrk7kzWKr5MobPjR7R%2F1gFsWNJxoEJptTQxqA%3D&reserved=0
> >
> >
> >
> > On Thu, Jan 16, 2020 at 12:59 PM Josh Tynjala <
> joshtynjala@bowlerhat.dev>
> > wrote:
> >
> > > Thank you, Harbs! Wrapping the variable name in a
> > > goog.reflect.objectProperty() call works perfectly. This is
> exactly
> why I
> > > started this thread, to see if anyone could suggest possible
> alternatives.
> > >
> > > Thankfully, we can keep the same simple data structure as
> before,
> and my
> > > initial proposal with functions can be forgotten. In a release
> build, I can
> > > see that goog.reflect.objectProperty() calls are replaced by a
> simple
> > > string literal (containing the minified variable name), so we
> don't
> have to
> > > worry about extra performance impact.
> > >
> > > --
> > > Josh Tynjala
> > > Bowler Hat LLC <
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7Cb7700e87eb404fce199308d7aa7368fb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637165286896410173&sdata=lMDPEZBrk7kzWKr5MobPjR7R%2F1gFsWNJxoEJptTQxqA%3D&reserved=0
> >
> > >
> > >
> > > On Wed, Jan 15, 2020 at 8:32 PM Harbs <ha...@gmail.com>
> wrote:
> > >
> > >> Sounds good!
> > >>
> > >>
> > >>
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FType-Based-Property-Renaming&data=02%7C01%7Caharui%40adobe.com%7Cb7700e87eb404fce199308d7aa7368fb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637165286896410173&sdata=xbvdLH%2FKesfH%2BXLc8AIOdsUsoeS%2BF6hMBiVV3fDXHIc%3D&reserved=0
> > >> <
> > >>
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FType-Based-Property-Renaming&data=02%7C01%7Caharui%40adobe.com%7Cb7700e87eb404fce199308d7aa7368fb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637165286896410173&sdata=xbvdLH%2FKesfH%2BXLc8AIOdsUsoeS%2BF6hMBiVV3fDXHIc%3D&reserved=0
> > >> >
> > >>
> > >> The function seems to be goog.reflect.objectProperty()
> > >>
> > >> I’m not sure exactly how it works though.
> > >>
> > >> > On Jan 16, 2020, at 1:37 AM, Greg Dove <greg.dove@gmail.com
> >
> wrote:
> > >> >
> > >> > actually just as another fyi, Harbs pointed out some
> intriguing
> goog
> > >> > methods recently - I don't have an immediate reference to it
> sorry. One
> > >> of
> > >> > those seemed to allow for access to renamed names by
> wrapping the
> > >> original
> > >> > names in a 'magic' method that presumably GCC recognises
> (but
> presumably
> > >> > returns the name unchanged in debug mode)
> > >> >
> > >> >
> > >> > On Thu, Jan 16, 2020 at 12:33 PM Greg Dove <
> greg.dove@gmail.com>
> wrote:
> > >> >
> > >> >> 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 <
> > >> joshtynjala@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%7Cb7700e87eb404fce199308d7aa7368fb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637165286896410173&sdata=Mr4EdF%2Bm%2B3T%2BAskoYeXXlle5PnSgON%2B5jgPC%2F0Zxr0w%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%7Cb7700e87eb404fce199308d7aa7368fb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637165286896410173&sdata=lMDPEZBrk7kzWKr5MobPjR7R%2F1gFsWNJxoEJptTQxqA%3D&reserved=0
> >
> > >> >>>
> > >> >>
> > >>
> > >>
> >
> >
> >
>
>
>
Re: MXML and warn-public vars
Posted by Josh Tynjala <jo...@bowlerhat.dev>.
Thank you for the tips, Alex. Much appreciated. With your help, I've
determined how to use Closure compiler's Java API to prevent the renaming
of a specific public variable that has not been @export-ed. Now, I should
be able to expand this prototype to a full version that prevents the
renaming of all public variables.
--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>
On Sun, Jan 19, 2020 at 4:58 PM Alex Harui <ah...@adobe.com.invalid> wrote:
> In response to your prior post, the reason I am saying it removes control
> is because I didn't see any option to not have the compiler output
> goog.reflect.objectProperty and I'm not clear everyone will want/need it.
>
> Regarding how to control Closure Compiler's renaming, the details might be
> changing because I believe I saw that Google refactored the renamer. At a
> high-level, you probably know most of this, but for other folks reading,
> the Closure Compiler is a set of Java Classes that form a series of
> Compiler Passes. Each Pass takes information (sometimes source, sometimes
> the AST, sometimes other information, and modifies the AST. IIRC, a final
> pass generates the output. There might be more than one pass for output.
>
> The renaming pass we currently use can output as well as accept a file of
> rename mappings. I’m confident we can subclass or modify and replace the
> renaming pass and feed it a set of mappings. If you look in the
> royale-compiler source, we've already done this for some other passes.
> Look through the Closure compiler source for what happens to the compiler
> options:
>
> --variable_map_input_file
> --property_map_input_file
>
> You can build examples/mxroyale/TourDeFlexModules which outputs these
> files to see what is in them.
>
>
> We should also see if we can agree on the scenarios and likelihood of
> property access "by name". I can quickly think of:
>
> A) MXML setting properties by reference (high usage)
> B) MXML setting properties by value (high usage)
> C) Serializers/Deserializers (moderate usage)
> D) [] bracket access by Literal (occasional usage)
> E) [] bracket access by String Variable (occasional usage)
> F) [] bracket access by Expression (infrequent usage)
>
> Exports can solve A. The compiler can easily detect D & E and prevent
> renaming. For C, we "could" autogenerate exports for any classes with
> [RemoteClass] metadata or autogenerate getter/setters.
>
> To me, the only difficult case is F and it will rarely happen. Maybe we
> can detect those and warn on that.
>
> Of course, I could be wrong...
> -Alex
>
>
> On 1/17/20, 10:08 AM, "Josh Tynjala" <jo...@bowlerhat.dev> wrote:
>
> Comments inline.
>
> On Thursday, January 16, 2020, Alex Harui <ah...@adobe.com.invalid>
> wrote:
> > Maybe we should start by agreeing on facts and then goals and then
> discuss solutions.
>
> Yes, I think that's a good place to start.
>
> >
> > Here are some facts that come to mind, not a complete list.
> >
> > 1) An export does not prevent renaming. It builds an alias. All
> references within the set of sources to be minified are renamed.
>
> Agreed.
>
> > 2) Closure's export mechanism only works on non-scalars (Object,
> Arrays,
> Functions) and not Number, String, Boolean because non-scalars are
> pass-by-reference instead of pass-by-value
>
> Agreed.
>
> > 3) The Closure Compiler is open source and designed to be extended
>
> Agreed.
>
> > 4) Use of goog.reflect.objectProperty is not necessarily the only
> way to
> control renaming. It is the way recommended by Google for those who
> can't
> extend the compiler. We are not constrained to modify our output
> because
> we have control over the compiler.
>
> Could you share some details how we might have more control over
> Closure
> compiler's renaming? It sounds like you know, at least somewhat, how
> to use
> its lower-level Java APIs, but you've never shared the details when
> you've
> mentioned them in this thread or in the past.
>
> I should add that I've personally tried to research this topic myself,
> but
> I had a very hard time finding any information that wasn't just someone
> explaining to a JS developer that they needed to modify their JS code.
> I
> eventually couldn't justify spending more time to keep looking.
>
> > 5) The compiler knows things about how properties were accessed.
> That
> information is lost in the output in many cases. Therefore, it should
> be
> better to inform the Google minifier directly from the Royale compiler,
> instead of leaving hints in the output.
>
> Agreed. I'm personally not fully convinced that the Royale compiler has
> enough information for dynamic stuff (like for serialization with type
> Object), but that may be due to ignorance about Closure compiler's
> capabilities. Even without knowing how it works, I can imagine how it
> might
> be relatively easy to prevent renaming of public variables, but the
> dynamic
> stuff is trickier. For the dynamic stuff, maybe it's just a matter of
> Closure detecting when a variable is typed as Object, and then it can
> switch to ["string"] syntax on its own (instead of us doing it in the
> debug
> build, like with -js-dynamic-access-unknown-members).
>
> > 7) We are pretty close to allowing renaming across modules. It was
> working for a while, but a scenario popped up that isn't currently
> handled. We can pre-load the Closure renamer with a name map.
>
> I haven't looked in detail at the module implementation and don't plan
> to,
> but I understand it well enough at a high level to say "agreed" here
> too
>
> >
> > These are hypotheses, and not proven facts.
> > 8) The big gain from not exporting everything is in dead code removal
> instead of shorter variable names
>
> Agreed, personally. It seems like others have expressed interest in
> both,
> though. I hope that they'll be willing to prioriitze dead code removal,
> since it will probably have the bigger impact (my own tests removing
> @export have been promising in this regard).
>
> > 9) Renaming can complicate and slow serialization/deserialization
>
> Agreed, and this is the harder portion to get working, I think.
>
> However, if release builds didn't rename public variables, and also
> didn't
> rename dynamic accesses, that would remove my biggest frustration with
> how
> ActionScript works in Royale/JS compared to SWF. If both kept their
> original names, things that feel broken today would "just work" again.
>
> >
> > IMO, we want to be heading in the direction of A) allowing control
> over
> what gets renamed
>
> Agreed, but as I said before, I think that dead code removal will have
> more
> impact than control over renaming, so if it's one or the other, I'm
> okay
> with no control over renaming.
>
> > B) capturing information from the compiler,
> > C) controlling the set of renames and exports directly, not through
> the
> output.
>
> Agreed, being able to pass information Closure compiler on the Java
> side
> would be better. than through the JS output
>
>
> >
> > My 2 cents,
> > -Alex
> >
> >
> > On 1/16/20, 2:48 PM, "Josh Tynjala" <jo...@bowlerhat.dev>
> wrote:
> >
> > Some additional context, if anyone is interested.
> >
> > At the request of Harbs, I am currently investigating how we
> might
> remove
> > @export from our generated JS code to improve the minimization
> even
> more.
> > When I modified the compiler to skip emitting @export in some
> places,
> a
> > release build of TourDeJewel was initially broken. When I added
> > goog.reflect.objectProperty(), not only did it fix setting public
> variables
> > in MXML, it also made that release build of TourDeJewel start
> working
> again.
> >
> > --
> > Josh Tynjala
> > Bowler Hat LLC <
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C1e9c2c4ae9d049b2896708d79b7843c7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148813154391097&sdata=8T%2B4UIVZrakKMBkAs2qOcwalYaCVJuMxHMKPYTnbvxM%3D&reserved=0
> >
> >
> >
> > On Thu, Jan 16, 2020 at 12:59 PM Josh Tynjala <
> joshtynjala@bowlerhat.dev>
> > wrote:
> >
> > > Thank you, Harbs! Wrapping the variable name in a
> > > goog.reflect.objectProperty() call works perfectly. This is
> exactly
> why I
> > > started this thread, to see if anyone could suggest possible
> alternatives.
> > >
> > > Thankfully, we can keep the same simple data structure as
> before,
> and my
> > > initial proposal with functions can be forgotten. In a release
> build, I can
> > > see that goog.reflect.objectProperty() calls are replaced by a
> simple
> > > string literal (containing the minified variable name), so we
> don't
> have to
> > > worry about extra performance impact.
> > >
> > > --
> > > Josh Tynjala
> > > Bowler Hat LLC <
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C1e9c2c4ae9d049b2896708d79b7843c7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148813154391097&sdata=8T%2B4UIVZrakKMBkAs2qOcwalYaCVJuMxHMKPYTnbvxM%3D&reserved=0
> >
> > >
> > >
> > > On Wed, Jan 15, 2020 at 8:32 PM Harbs <ha...@gmail.com>
> wrote:
> > >
> > >> Sounds good!
> > >>
> > >>
> > >>
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FType-Based-Property-Renaming&data=02%7C01%7Caharui%40adobe.com%7C1e9c2c4ae9d049b2896708d79b7843c7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148813154391097&sdata=IzzY7%2BhSQ9iQr9GIKd16XD%2FfGwxB50aN6J0Mzb%2BEcWA%3D&reserved=0
> > >> <
> > >>
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FType-Based-Property-Renaming&data=02%7C01%7Caharui%40adobe.com%7C1e9c2c4ae9d049b2896708d79b7843c7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148813154391097&sdata=IzzY7%2BhSQ9iQr9GIKd16XD%2FfGwxB50aN6J0Mzb%2BEcWA%3D&reserved=0
> > >> >
> > >>
> > >> The function seems to be goog.reflect.objectProperty()
> > >>
> > >> I’m not sure exactly how it works though.
> > >>
> > >> > On Jan 16, 2020, at 1:37 AM, Greg Dove <greg.dove@gmail.com
> >
> wrote:
> > >> >
> > >> > actually just as another fyi, Harbs pointed out some
> intriguing
> goog
> > >> > methods recently - I don't have an immediate reference to it
> sorry. One
> > >> of
> > >> > those seemed to allow for access to renamed names by
> wrapping the
> > >> original
> > >> > names in a 'magic' method that presumably GCC recognises
> (but
> presumably
> > >> > returns the name unchanged in debug mode)
> > >> >
> > >> >
> > >> > On Thu, Jan 16, 2020 at 12:33 PM Greg Dove <
> greg.dove@gmail.com>
> wrote:
> > >> >
> > >> >> 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 <
> > >> joshtynjala@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%7C1e9c2c4ae9d049b2896708d79b7843c7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148813154391097&sdata=aA3JAnaQuU1GrF%2B4vmTo1Lhn38gDM4UtG2%2FdbmwBnjQ%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%7C1e9c2c4ae9d049b2896708d79b7843c7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148813154391097&sdata=8T%2B4UIVZrakKMBkAs2qOcwalYaCVJuMxHMKPYTnbvxM%3D&reserved=0
> >
> > >> >>>
> > >> >>
> > >>
> > >>
> >
> >
> >
>
>
>
Re: MXML and warn-public vars
Posted by Alex Harui <ah...@adobe.com.INVALID>.
In response to your prior post, the reason I am saying it removes control is because I didn't see any option to not have the compiler output goog.reflect.objectProperty and I'm not clear everyone will want/need it.
Regarding how to control Closure Compiler's renaming, the details might be changing because I believe I saw that Google refactored the renamer. At a high-level, you probably know most of this, but for other folks reading, the Closure Compiler is a set of Java Classes that form a series of Compiler Passes. Each Pass takes information (sometimes source, sometimes the AST, sometimes other information, and modifies the AST. IIRC, a final pass generates the output. There might be more than one pass for output.
The renaming pass we currently use can output as well as accept a file of rename mappings. I’m confident we can subclass or modify and replace the renaming pass and feed it a set of mappings. If you look in the royale-compiler source, we've already done this for some other passes. Look through the Closure compiler source for what happens to the compiler options:
--variable_map_input_file
--property_map_input_file
You can build examples/mxroyale/TourDeFlexModules which outputs these files to see what is in them.
We should also see if we can agree on the scenarios and likelihood of property access "by name". I can quickly think of:
A) MXML setting properties by reference (high usage)
B) MXML setting properties by value (high usage)
C) Serializers/Deserializers (moderate usage)
D) [] bracket access by Literal (occasional usage)
E) [] bracket access by String Variable (occasional usage)
F) [] bracket access by Expression (infrequent usage)
Exports can solve A. The compiler can easily detect D & E and prevent renaming. For C, we "could" autogenerate exports for any classes with [RemoteClass] metadata or autogenerate getter/setters.
To me, the only difficult case is F and it will rarely happen. Maybe we can detect those and warn on that.
Of course, I could be wrong...
-Alex
On 1/17/20, 10:08 AM, "Josh Tynjala" <jo...@bowlerhat.dev> wrote:
Comments inline.
On Thursday, January 16, 2020, Alex Harui <ah...@adobe.com.invalid> wrote:
> Maybe we should start by agreeing on facts and then goals and then
discuss solutions.
Yes, I think that's a good place to start.
>
> Here are some facts that come to mind, not a complete list.
>
> 1) An export does not prevent renaming. It builds an alias. All
references within the set of sources to be minified are renamed.
Agreed.
> 2) Closure's export mechanism only works on non-scalars (Object, Arrays,
Functions) and not Number, String, Boolean because non-scalars are
pass-by-reference instead of pass-by-value
Agreed.
> 3) The Closure Compiler is open source and designed to be extended
Agreed.
> 4) Use of goog.reflect.objectProperty is not necessarily the only way to
control renaming. It is the way recommended by Google for those who can't
extend the compiler. We are not constrained to modify our output because
we have control over the compiler.
Could you share some details how we might have more control over Closure
compiler's renaming? It sounds like you know, at least somewhat, how to use
its lower-level Java APIs, but you've never shared the details when you've
mentioned them in this thread or in the past.
I should add that I've personally tried to research this topic myself, but
I had a very hard time finding any information that wasn't just someone
explaining to a JS developer that they needed to modify their JS code. I
eventually couldn't justify spending more time to keep looking.
> 5) The compiler knows things about how properties were accessed. That
information is lost in the output in many cases. Therefore, it should be
better to inform the Google minifier directly from the Royale compiler,
instead of leaving hints in the output.
Agreed. I'm personally not fully convinced that the Royale compiler has
enough information for dynamic stuff (like for serialization with type
Object), but that may be due to ignorance about Closure compiler's
capabilities. Even without knowing how it works, I can imagine how it might
be relatively easy to prevent renaming of public variables, but the dynamic
stuff is trickier. For the dynamic stuff, maybe it's just a matter of
Closure detecting when a variable is typed as Object, and then it can
switch to ["string"] syntax on its own (instead of us doing it in the debug
build, like with -js-dynamic-access-unknown-members).
> 7) We are pretty close to allowing renaming across modules. It was
working for a while, but a scenario popped up that isn't currently
handled. We can pre-load the Closure renamer with a name map.
I haven't looked in detail at the module implementation and don't plan to,
but I understand it well enough at a high level to say "agreed" here too
>
> These are hypotheses, and not proven facts.
> 8) The big gain from not exporting everything is in dead code removal
instead of shorter variable names
Agreed, personally. It seems like others have expressed interest in both,
though. I hope that they'll be willing to prioriitze dead code removal,
since it will probably have the bigger impact (my own tests removing
@export have been promising in this regard).
> 9) Renaming can complicate and slow serialization/deserialization
Agreed, and this is the harder portion to get working, I think.
However, if release builds didn't rename public variables, and also didn't
rename dynamic accesses, that would remove my biggest frustration with how
ActionScript works in Royale/JS compared to SWF. If both kept their
original names, things that feel broken today would "just work" again.
>
> IMO, we want to be heading in the direction of A) allowing control over
what gets renamed
Agreed, but as I said before, I think that dead code removal will have more
impact than control over renaming, so if it's one or the other, I'm okay
with no control over renaming.
> B) capturing information from the compiler,
> C) controlling the set of renames and exports directly, not through the
output.
Agreed, being able to pass information Closure compiler on the Java side
would be better. than through the JS output
>
> My 2 cents,
> -Alex
>
>
> On 1/16/20, 2:48 PM, "Josh Tynjala" <jo...@bowlerhat.dev> wrote:
>
> Some additional context, if anyone is interested.
>
> At the request of Harbs, I am currently investigating how we might
remove
> @export from our generated JS code to improve the minimization even
more.
> When I modified the compiler to skip emitting @export in some places,
a
> release build of TourDeJewel was initially broken. When I added
> goog.reflect.objectProperty(), not only did it fix setting public
variables
> in MXML, it also made that release build of TourDeJewel start working
again.
>
> --
> Josh Tynjala
> Bowler Hat LLC <
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C1e9c2c4ae9d049b2896708d79b7843c7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148813154391097&sdata=8T%2B4UIVZrakKMBkAs2qOcwalYaCVJuMxHMKPYTnbvxM%3D&reserved=0
>
>
>
> On Thu, Jan 16, 2020 at 12:59 PM Josh Tynjala <
joshtynjala@bowlerhat.dev>
> wrote:
>
> > Thank you, Harbs! Wrapping the variable name in a
> > goog.reflect.objectProperty() call works perfectly. This is exactly
why I
> > started this thread, to see if anyone could suggest possible
alternatives.
> >
> > Thankfully, we can keep the same simple data structure as before,
and my
> > initial proposal with functions can be forgotten. In a release
build, I can
> > see that goog.reflect.objectProperty() calls are replaced by a
simple
> > string literal (containing the minified variable name), so we don't
have to
> > worry about extra performance impact.
> >
> > --
> > Josh Tynjala
> > Bowler Hat LLC <
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C1e9c2c4ae9d049b2896708d79b7843c7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148813154391097&sdata=8T%2B4UIVZrakKMBkAs2qOcwalYaCVJuMxHMKPYTnbvxM%3D&reserved=0
>
> >
> >
> > On Wed, Jan 15, 2020 at 8:32 PM Harbs <ha...@gmail.com> wrote:
> >
> >> Sounds good!
> >>
> >>
> >>
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FType-Based-Property-Renaming&data=02%7C01%7Caharui%40adobe.com%7C1e9c2c4ae9d049b2896708d79b7843c7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148813154391097&sdata=IzzY7%2BhSQ9iQr9GIKd16XD%2FfGwxB50aN6J0Mzb%2BEcWA%3D&reserved=0
> >> <
> >>
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FType-Based-Property-Renaming&data=02%7C01%7Caharui%40adobe.com%7C1e9c2c4ae9d049b2896708d79b7843c7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148813154391097&sdata=IzzY7%2BhSQ9iQr9GIKd16XD%2FfGwxB50aN6J0Mzb%2BEcWA%3D&reserved=0
> >> >
> >>
> >> The function seems to be goog.reflect.objectProperty()
> >>
> >> I’m not sure exactly how it works though.
> >>
> >> > On Jan 16, 2020, at 1:37 AM, Greg Dove <gr...@gmail.com>
wrote:
> >> >
> >> > actually just as another fyi, Harbs pointed out some intriguing
goog
> >> > methods recently - I don't have an immediate reference to it
sorry. One
> >> of
> >> > those seemed to allow for access to renamed names by wrapping the
> >> original
> >> > names in a 'magic' method that presumably GCC recognises (but
presumably
> >> > returns the name unchanged in debug mode)
> >> >
> >> >
> >> > On Thu, Jan 16, 2020 at 12:33 PM Greg Dove <gr...@gmail.com>
wrote:
> >> >
> >> >> 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 <
> >> joshtynjala@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%7C1e9c2c4ae9d049b2896708d79b7843c7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148813154391097&sdata=aA3JAnaQuU1GrF%2B4vmTo1Lhn38gDM4UtG2%2FdbmwBnjQ%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%7C1e9c2c4ae9d049b2896708d79b7843c7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148813154391097&sdata=8T%2B4UIVZrakKMBkAs2qOcwalYaCVJuMxHMKPYTnbvxM%3D&reserved=0
>
> >> >>>
> >> >>
> >>
> >>
>
>
>
Re: MXML and warn-public vars
Posted by Josh Tynjala <jo...@bowlerhat.dev>.
Comments inline.
On Thursday, January 16, 2020, Alex Harui <ah...@adobe.com.invalid> wrote:
> Maybe we should start by agreeing on facts and then goals and then
discuss solutions.
Yes, I think that's a good place to start.
>
> Here are some facts that come to mind, not a complete list.
>
> 1) An export does not prevent renaming. It builds an alias. All
references within the set of sources to be minified are renamed.
Agreed.
> 2) Closure's export mechanism only works on non-scalars (Object, Arrays,
Functions) and not Number, String, Boolean because non-scalars are
pass-by-reference instead of pass-by-value
Agreed.
> 3) The Closure Compiler is open source and designed to be extended
Agreed.
> 4) Use of goog.reflect.objectProperty is not necessarily the only way to
control renaming. It is the way recommended by Google for those who can't
extend the compiler. We are not constrained to modify our output because
we have control over the compiler.
Could you share some details how we might have more control over Closure
compiler's renaming? It sounds like you know, at least somewhat, how to use
its lower-level Java APIs, but you've never shared the details when you've
mentioned them in this thread or in the past.
I should add that I've personally tried to research this topic myself, but
I had a very hard time finding any information that wasn't just someone
explaining to a JS developer that they needed to modify their JS code. I
eventually couldn't justify spending more time to keep looking.
> 5) The compiler knows things about how properties were accessed. That
information is lost in the output in many cases. Therefore, it should be
better to inform the Google minifier directly from the Royale compiler,
instead of leaving hints in the output.
Agreed. I'm personally not fully convinced that the Royale compiler has
enough information for dynamic stuff (like for serialization with type
Object), but that may be due to ignorance about Closure compiler's
capabilities. Even without knowing how it works, I can imagine how it might
be relatively easy to prevent renaming of public variables, but the dynamic
stuff is trickier. For the dynamic stuff, maybe it's just a matter of
Closure detecting when a variable is typed as Object, and then it can
switch to ["string"] syntax on its own (instead of us doing it in the debug
build, like with -js-dynamic-access-unknown-members).
> 7) We are pretty close to allowing renaming across modules. It was
working for a while, but a scenario popped up that isn't currently
handled. We can pre-load the Closure renamer with a name map.
I haven't looked in detail at the module implementation and don't plan to,
but I understand it well enough at a high level to say "agreed" here too
>
> These are hypotheses, and not proven facts.
> 8) The big gain from not exporting everything is in dead code removal
instead of shorter variable names
Agreed, personally. It seems like others have expressed interest in both,
though. I hope that they'll be willing to prioriitze dead code removal,
since it will probably have the bigger impact (my own tests removing
@export have been promising in this regard).
> 9) Renaming can complicate and slow serialization/deserialization
Agreed, and this is the harder portion to get working, I think.
However, if release builds didn't rename public variables, and also didn't
rename dynamic accesses, that would remove my biggest frustration with how
ActionScript works in Royale/JS compared to SWF. If both kept their
original names, things that feel broken today would "just work" again.
>
> IMO, we want to be heading in the direction of A) allowing control over
what gets renamed
Agreed, but as I said before, I think that dead code removal will have more
impact than control over renaming, so if it's one or the other, I'm okay
with no control over renaming.
> B) capturing information from the compiler,
> C) controlling the set of renames and exports directly, not through the
output.
Agreed, being able to pass information Closure compiler on the Java side
would be better. than through the JS output
>
> My 2 cents,
> -Alex
>
>
> On 1/16/20, 2:48 PM, "Josh Tynjala" <jo...@bowlerhat.dev> wrote:
>
> Some additional context, if anyone is interested.
>
> At the request of Harbs, I am currently investigating how we might
remove
> @export from our generated JS code to improve the minimization even
more.
> When I modified the compiler to skip emitting @export in some places,
a
> release build of TourDeJewel was initially broken. When I added
> goog.reflect.objectProperty(), not only did it fix setting public
variables
> in MXML, it also made that release build of TourDeJewel start working
again.
>
> --
> Josh Tynjala
> Bowler Hat LLC <
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7Cc060c7977c184a07aa2708d79ad6357a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148117120345421&sdata=ysm%2FJ2FfEK9jKlj4gND5LIFLihlaP6pHZYs0eueIihs%3D&reserved=0
>
>
>
> On Thu, Jan 16, 2020 at 12:59 PM Josh Tynjala <
joshtynjala@bowlerhat.dev>
> wrote:
>
> > Thank you, Harbs! Wrapping the variable name in a
> > goog.reflect.objectProperty() call works perfectly. This is exactly
why I
> > started this thread, to see if anyone could suggest possible
alternatives.
> >
> > Thankfully, we can keep the same simple data structure as before,
and my
> > initial proposal with functions can be forgotten. In a release
build, I can
> > see that goog.reflect.objectProperty() calls are replaced by a
simple
> > string literal (containing the minified variable name), so we don't
have to
> > worry about extra performance impact.
> >
> > --
> > Josh Tynjala
> > Bowler Hat LLC <
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7Cc060c7977c184a07aa2708d79ad6357a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148117120355415&sdata=6fT85c%2FQJ8aXEYf%2FQgZ%2BcoEj1%2F0%2BfmskfdvHXuLeXOg%3D&reserved=0
>
> >
> >
> > On Wed, Jan 15, 2020 at 8:32 PM Harbs <ha...@gmail.com> wrote:
> >
> >> Sounds good!
> >>
> >>
> >>
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FType-Based-Property-Renaming&data=02%7C01%7Caharui%40adobe.com%7Cc060c7977c184a07aa2708d79ad6357a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148117120355415&sdata=ncKq3dWJbDBJB6EylRMugca0Ck512sngA6O6KQ9IupQ%3D&reserved=0
> >> <
> >>
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FType-Based-Property-Renaming&data=02%7C01%7Caharui%40adobe.com%7Cc060c7977c184a07aa2708d79ad6357a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148117120355415&sdata=ncKq3dWJbDBJB6EylRMugca0Ck512sngA6O6KQ9IupQ%3D&reserved=0
> >> >
> >>
> >> The function seems to be goog.reflect.objectProperty()
> >>
> >> I’m not sure exactly how it works though.
> >>
> >> > On Jan 16, 2020, at 1:37 AM, Greg Dove <gr...@gmail.com>
wrote:
> >> >
> >> > actually just as another fyi, Harbs pointed out some intriguing
goog
> >> > methods recently - I don't have an immediate reference to it
sorry. One
> >> of
> >> > those seemed to allow for access to renamed names by wrapping the
> >> original
> >> > names in a 'magic' method that presumably GCC recognises (but
presumably
> >> > returns the name unchanged in debug mode)
> >> >
> >> >
> >> > On Thu, Jan 16, 2020 at 12:33 PM Greg Dove <gr...@gmail.com>
wrote:
> >> >
> >> >> 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 <
> >> joshtynjala@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%7Cc060c7977c184a07aa2708d79ad6357a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148117120355415&sdata=a3kRb8bAWJfR%2BiTmsdk11%2FfvdXgSyYrJXDFfBY7nSok%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%7Cc060c7977c184a07aa2708d79ad6357a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148117120355415&sdata=6fT85c%2FQJ8aXEYf%2FQgZ%2BcoEj1%2F0%2BfmskfdvHXuLeXOg%3D&reserved=0
>
> >> >>>
> >> >>
> >>
> >>
>
>
>
Re: MXML and warn-public vars
Posted by Alex Harui <ah...@adobe.com.INVALID>.
I'm not surprised that this change fixed a problem caused by removing @export. This is not a question about the technical accuracy of your work, which is always very good. This just doesn't feel like the right solution. Maybe we should start by agreeing on facts and then goals and then discuss solutions. This solution seems to take control of the output away from folks who will want different output and is solving a specific scenario and not the general problem in a less optimal way.
Here are some facts that come to mind, not a complete list.
1) An export does not prevent renaming. It builds an alias. All references within the set of sources to be minified are renamed.
2) Closure's export mechanism only works on non-scalars (Object, Arrays, Functions) and not Number, String, Boolean because non-scalars are pass-by-reference instead of pass-by-value
3) The Closure Compiler is open source and designed to be extended
4) Use of goog.reflect.objectProperty is not necessarily the only way to control renaming. It is the way recommended by Google for those who can't extend the compiler. We are not constrained to modify our output because we have control over the compiler.
5) The compiler knows things about how properties were accessed. That information is lost in the output in many cases. Therefore, it should be better to inform the Google minifier directly from the Royale compiler, instead of leaving hints in the output.
6) All getter/setters are not renamed, but are not exported.
7) We are pretty close to allowing renaming across modules. It was working for a while, but a scenario popped up that isn't currently handled. We can pre-load the Closure renamer with a name map.
These are hypotheses, and not proven facts.
8) The big gain from not exporting everything is in dead code removal instead of shorter variable names
9) Renaming can complicate and slow serialization/deserialization
IMO, we want to be heading in the direction of A) allowing control over what gets renamed, B) capturing information from the compiler, C) controlling the set of renames and exports directly, not through the output.
My 2 cents,
-Alex
On 1/16/20, 2:48 PM, "Josh Tynjala" <jo...@bowlerhat.dev> wrote:
Some additional context, if anyone is interested.
At the request of Harbs, I am currently investigating how we might remove
@export from our generated JS code to improve the minimization even more.
When I modified the compiler to skip emitting @export in some places, a
release build of TourDeJewel was initially broken. When I added
goog.reflect.objectProperty(), not only did it fix setting public variables
in MXML, it also made that release build of TourDeJewel start working again.
--
Josh Tynjala
Bowler Hat LLC <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7Cc060c7977c184a07aa2708d79ad6357a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148117120345421&sdata=ysm%2FJ2FfEK9jKlj4gND5LIFLihlaP6pHZYs0eueIihs%3D&reserved=0>
On Thu, Jan 16, 2020 at 12:59 PM Josh Tynjala <jo...@bowlerhat.dev>
wrote:
> Thank you, Harbs! Wrapping the variable name in a
> goog.reflect.objectProperty() call works perfectly. This is exactly why I
> started this thread, to see if anyone could suggest possible alternatives.
>
> Thankfully, we can keep the same simple data structure as before, and my
> initial proposal with functions can be forgotten. In a release build, I can
> see that goog.reflect.objectProperty() calls are replaced by a simple
> string literal (containing the minified variable name), so we don't have to
> worry about extra performance impact.
>
> --
> Josh Tynjala
> Bowler Hat LLC <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7Cc060c7977c184a07aa2708d79ad6357a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148117120355415&sdata=6fT85c%2FQJ8aXEYf%2FQgZ%2BcoEj1%2F0%2BfmskfdvHXuLeXOg%3D&reserved=0>
>
>
> On Wed, Jan 15, 2020 at 8:32 PM Harbs <ha...@gmail.com> wrote:
>
>> Sounds good!
>>
>>
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FType-Based-Property-Renaming&data=02%7C01%7Caharui%40adobe.com%7Cc060c7977c184a07aa2708d79ad6357a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148117120355415&sdata=ncKq3dWJbDBJB6EylRMugca0Ck512sngA6O6KQ9IupQ%3D&reserved=0
>> <
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FType-Based-Property-Renaming&data=02%7C01%7Caharui%40adobe.com%7Cc060c7977c184a07aa2708d79ad6357a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148117120355415&sdata=ncKq3dWJbDBJB6EylRMugca0Ck512sngA6O6KQ9IupQ%3D&reserved=0
>> >
>>
>> The function seems to be goog.reflect.objectProperty()
>>
>> I’m not sure exactly how it works though.
>>
>> > On Jan 16, 2020, at 1:37 AM, Greg Dove <gr...@gmail.com> wrote:
>> >
>> > actually just as another fyi, Harbs pointed out some intriguing goog
>> > methods recently - I don't have an immediate reference to it sorry. One
>> of
>> > those seemed to allow for access to renamed names by wrapping the
>> original
>> > names in a 'magic' method that presumably GCC recognises (but presumably
>> > returns the name unchanged in debug mode)
>> >
>> >
>> > On Thu, Jan 16, 2020 at 12:33 PM Greg Dove <gr...@gmail.com> wrote:
>> >
>> >> 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 <
>> joshtynjala@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%7Cc060c7977c184a07aa2708d79ad6357a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148117120355415&sdata=a3kRb8bAWJfR%2BiTmsdk11%2FfvdXgSyYrJXDFfBY7nSok%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%7Cc060c7977c184a07aa2708d79ad6357a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148117120355415&sdata=6fT85c%2FQJ8aXEYf%2FQgZ%2BcoEj1%2F0%2BfmskfdvHXuLeXOg%3D&reserved=0>
>> >>>
>> >>
>>
>>
Re: MXML and warn-public vars
Posted by Josh Tynjala <jo...@bowlerhat.dev>.
Some additional context, if anyone is interested.
At the request of Harbs, I am currently investigating how we might remove
@export from our generated JS code to improve the minimization even more.
When I modified the compiler to skip emitting @export in some places, a
release build of TourDeJewel was initially broken. When I added
goog.reflect.objectProperty(), not only did it fix setting public variables
in MXML, it also made that release build of TourDeJewel start working again.
--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>
On Thu, Jan 16, 2020 at 12:59 PM Josh Tynjala <jo...@bowlerhat.dev>
wrote:
> Thank you, Harbs! Wrapping the variable name in a
> goog.reflect.objectProperty() call works perfectly. This is exactly why I
> started this thread, to see if anyone could suggest possible alternatives.
>
> Thankfully, we can keep the same simple data structure as before, and my
> initial proposal with functions can be forgotten. In a release build, I can
> see that goog.reflect.objectProperty() calls are replaced by a simple
> string literal (containing the minified variable name), so we don't have to
> worry about extra performance impact.
>
> --
> Josh Tynjala
> Bowler Hat LLC <https://bowlerhat.dev>
>
>
> On Wed, Jan 15, 2020 at 8:32 PM Harbs <ha...@gmail.com> wrote:
>
>> Sounds good!
>>
>>
>> https://github.com/google/closure-compiler/wiki/Type-Based-Property-Renaming
>> <
>> https://github.com/google/closure-compiler/wiki/Type-Based-Property-Renaming
>> >
>>
>> The function seems to be goog.reflect.objectProperty()
>>
>> I’m not sure exactly how it works though.
>>
>> > On Jan 16, 2020, at 1:37 AM, Greg Dove <gr...@gmail.com> wrote:
>> >
>> > actually just as another fyi, Harbs pointed out some intriguing goog
>> > methods recently - I don't have an immediate reference to it sorry. One
>> of
>> > those seemed to allow for access to renamed names by wrapping the
>> original
>> > names in a 'magic' method that presumably GCC recognises (but presumably
>> > returns the name unchanged in debug mode)
>> >
>> >
>> > On Thu, Jan 16, 2020 at 12:33 PM Greg Dove <gr...@gmail.com> wrote:
>> >
>> >> 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 <
>> joshtynjala@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>
>> >>>
>> >>
>>
>>
Re: MXML and warn-public vars
Posted by Greg Dove <gr...@gmail.com>.
That sounds great, thanks for working on that Josh!
I was meaning to take a look into the same goog stuff for possible
optimizations in reflection data and AMF, but I don't think any of that is
in the same league as the improvement you just made (because they currently
work in release build as-is). I am away on vacation for a week in a few
days time, so probably won't get there until afterwards.
On Fri, Jan 17, 2020 at 9:59 AM Josh Tynjala <jo...@bowlerhat.dev>
wrote:
> Thank you, Harbs! Wrapping the variable name in a
> goog.reflect.objectProperty() call works perfectly. This is exactly why I
> started this thread, to see if anyone could suggest possible alternatives.
>
> Thankfully, we can keep the same simple data structure as before, and my
> initial proposal with functions can be forgotten. In a release build, I can
> see that goog.reflect.objectProperty() calls are replaced by a simple
> string literal (containing the minified variable name), so we don't have to
> worry about extra performance impact.
>
> --
> Josh Tynjala
> Bowler Hat LLC <https://bowlerhat.dev>
>
>
> On Wed, Jan 15, 2020 at 8:32 PM Harbs <ha...@gmail.com> wrote:
>
> > Sounds good!
> >
> >
> >
> https://github.com/google/closure-compiler/wiki/Type-Based-Property-Renaming
> > <
> >
> https://github.com/google/closure-compiler/wiki/Type-Based-Property-Renaming
> > >
> >
> > The function seems to be goog.reflect.objectProperty()
> >
> > I’m not sure exactly how it works though.
> >
> > > On Jan 16, 2020, at 1:37 AM, Greg Dove <gr...@gmail.com> wrote:
> > >
> > > actually just as another fyi, Harbs pointed out some intriguing goog
> > > methods recently - I don't have an immediate reference to it sorry. One
> > of
> > > those seemed to allow for access to renamed names by wrapping the
> > original
> > > names in a 'magic' method that presumably GCC recognises (but
> presumably
> > > returns the name unchanged in debug mode)
> > >
> > >
> > > On Thu, Jan 16, 2020 at 12:33 PM Greg Dove <gr...@gmail.com>
> wrote:
> > >
> > >> 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 <
> > joshtynjala@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>
> > >>>
> > >>
> >
> >
>
Re: MXML and warn-public vars
Posted by Alex Harui <ah...@adobe.com.INVALID>.
On 1/16/20, 2:24 PM, "Harbs" <ha...@gmail.com> wrote:
In other words reflection?
The reflection classes already deal with this IIUC.
You’re right that a simplistic serializer will not work, but for that they wouldn’t be able to take advantage of the advanced minification anyway.
They might be able to use advanced optimization if we actually learn how to control renaming in the Closure Compiler. Then we could prevent renaming of public vars. We already prevent renaming of getters and setters.
The recommended solution should be to use reflection classes or disable the advanced closure options. That seems reasonable for this edge case.
If we learn how to control renaming ,then we won't have to worry about edge cases, nor will the users.
My 2 cents,
-Alex
> On Jan 17, 2020, at 12:19 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
>
>
> On 1/16/20, 2:14 PM, "Harbs" <ha...@gmail.com> wrote:
>
> What do you mean? This is the solution recommended by the compiler.
>
> What are your concerns?
>
> Someone writes their own deserializer. It is going to do something like:
>
> Var listOfProperties = ["firstName", "lastName"];
> Function deserialize(inputStream:String, c:Class):Object
> {
> Var foo:Object = new class();
> Var values:Array = inputStream.split(",");
> Var i=0;
> For each (var name:String in listOfProperties)
> {
> foo[name] = values[i++];
> }
> }
>
> How will the compiler know to use goog.reflect.objectProperty here? IMO, this change only solves the MXML problem but does not solve the other problems the public var warning was put in for.
>
> I must be missing something. I'm out of time for the next 6 or 7 hours.
>
> -Alex
>
>> On Jan 17, 2020, at 12:11 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>
>> OK. I still think this is not the right solution. As I said public vars are for more than MXML.
>
>
>
Re: MXML and warn-public vars
Posted by Harbs <ha...@gmail.com>.
In other words reflection?
The reflection classes already deal with this IIUC.
You’re right that a simplistic serializer will not work, but for that they wouldn’t be able to take advantage of the advanced minification anyway.
The recommended solution should be to use reflection classes or disable the advanced closure options. That seems reasonable for this edge case.
> On Jan 17, 2020, at 12:19 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
>
>
> On 1/16/20, 2:14 PM, "Harbs" <ha...@gmail.com> wrote:
>
> What do you mean? This is the solution recommended by the compiler.
>
> What are your concerns?
>
> Someone writes their own deserializer. It is going to do something like:
>
> Var listOfProperties = ["firstName", "lastName"];
> Function deserialize(inputStream:String, c:Class):Object
> {
> Var foo:Object = new class();
> Var values:Array = inputStream.split(",");
> Var i=0;
> For each (var name:String in listOfProperties)
> {
> foo[name] = values[i++];
> }
> }
>
> How will the compiler know to use goog.reflect.objectProperty here? IMO, this change only solves the MXML problem but does not solve the other problems the public var warning was put in for.
>
> I must be missing something. I'm out of time for the next 6 or 7 hours.
>
> -Alex
>
>> On Jan 17, 2020, at 12:11 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>
>> OK. I still think this is not the right solution. As I said public vars are for more than MXML.
>
>
>
Re: MXML and warn-public vars
Posted by Alex Harui <ah...@adobe.com.INVALID>.
On 1/16/20, 2:14 PM, "Harbs" <ha...@gmail.com> wrote:
What do you mean? This is the solution recommended by the compiler.
What are your concerns?
Someone writes their own deserializer. It is going to do something like:
Var listOfProperties = ["firstName", "lastName"];
Function deserialize(inputStream:String, c:Class):Object
{
Var foo:Object = new class();
Var values:Array = inputStream.split(",");
Var i=0;
For each (var name:String in listOfProperties)
{
foo[name] = values[i++];
}
}
How will the compiler know to use goog.reflect.objectProperty here? IMO, this change only solves the MXML problem but does not solve the other problems the public var warning was put in for.
I must be missing something. I'm out of time for the next 6 or 7 hours.
-Alex
> On Jan 17, 2020, at 12:11 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> OK. I still think this is not the right solution. As I said public vars are for more than MXML.
Re: MXML and warn-public vars
Posted by Harbs <ha...@gmail.com>.
What do you mean? This is the solution recommended by the compiler.
What are your concerns?
> On Jan 17, 2020, at 12:11 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> OK. I still think this is not the right solution. As I said public vars are for more than MXML.
Re: MXML and warn-public vars
Posted by Alex Harui <ah...@adobe.com.INVALID>.
On 1/16/20, 2:08 PM, "Harbs" <ha...@gmail.com> wrote:
Uh. No.
You’d see data = [function, 1, ‘publicVar', true, 'value’]
It’s a function call which returns the fed parameter.
OK. I still think this is not the right solution. As I said public vars are for more than MXML.
-Alex
> On Jan 17, 2020, at 12:06 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> And so when I have to debug the structure in js-debug, I will see
>
> data = [function, 1, function, true, 'value']
>
> And have no idea what property is being set? I'm not in favor of this change.
>
> The public var warning is not just for MXML. It is for any dynamic access by property name whether from web services, remote object or bracket access or any other user code. Seems like we should just find a way to prevent renaming of public vars. We should be able to feed some names to the Closure renaming pass.
>
> My 2 cents,
> -Alex
>
>
> On 1/16/20, 1:51 PM, "Josh Tynjala" <jo...@bowlerhat.dev> wrote:
>
> Before:
>
> var data = [
> Component,
> 1,
> 'publicVar',
> true,
> 'value'
> ]
>
> After (debug):
>
> var data = [
> Component,
> 1,
> goog.reflect.objectProperty('publicVar'),
> true,
> 'value'
> ]
>
> In a release build, Closure compiler replaces the function call completely
> with the minified name, so it ends up being like this:
>
> var data = [
> Component,
> 1,
> '<minified name here>',
> true,
> 'value'
> ]
>
> --
> Josh Tynjala
> Bowler Hat LLC <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7Cf0a04642179249d9c7a708d79ad0acda%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148093358424150&sdata=AwJpV1fXOpMhPZBz3fExK5qQFMNvBgnXhA%2FWyCMYztQ%3D&reserved=0>
>
>
> On Thu, Jan 16, 2020 at 1:38 PM Alex Harui <ah...@adobe.com.invalid> wrote:
>
>> Where does the goog.reflect.objectProperty appear in the output? In the
>> data stream?
>>
>>
>> On 1/16/20, 1:35 PM, "Harbs" <ha...@gmail.com> wrote:
>>
>> Amazing!
>>
>>> On Jan 16, 2020, at 10:59 PM, Josh Tynjala <
>> joshtynjala@bowlerhat.dev> wrote:
>>>
>>> Thank you, Harbs! Wrapping the variable name in a
>>> goog.reflect.objectProperty() call works perfectly. This is exactly
>> why I
>>> started this thread, to see if anyone could suggest possible
>> alternatives.
>>>
>>> Thankfully, we can keep the same simple data structure as before,
>> and my
>>> initial proposal with functions can be forgotten. In a release
>> build, I can
>>> see that goog.reflect.objectProperty() calls are replaced by a simple
>>> string literal (containing the minified variable name), so we don't
>> have to
>>> worry about extra performance impact.
>>>
>>> --
>>> Josh Tynjala
>>> Bowler Hat LLC <
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7Cf0a04642179249d9c7a708d79ad0acda%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148093358424150&sdata=AwJpV1fXOpMhPZBz3fExK5qQFMNvBgnXhA%2FWyCMYztQ%3D&reserved=0
>>>
>>>
>>>
>>> On Wed, Jan 15, 2020 at 8:32 PM Harbs <ha...@gmail.com> wrote:
>>>
>>>> Sounds good!
>>>>
>>>>
>>>>
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FType-Based-Property-Renaming&data=02%7C01%7Caharui%40adobe.com%7Cf0a04642179249d9c7a708d79ad0acda%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148093358424150&sdata=ojc6w7dbT1w5gNankVXBtexVITlxayadmvaxErl%2BcUk%3D&reserved=0
>>>> <
>>>>
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FType-Based-Property-Renaming&data=02%7C01%7Caharui%40adobe.com%7Cf0a04642179249d9c7a708d79ad0acda%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148093358429149&sdata=hYCWwIMYQDg6zgVL%2FSDrNojfHdrwP%2F%2FRrrGSrb21e3g%3D&reserved=0
>>>>>
>>>>
>>>> The function seems to be goog.reflect.objectProperty()
>>>>
>>>> I’m not sure exactly how it works though.
>>>>
>>>>> On Jan 16, 2020, at 1:37 AM, Greg Dove <gr...@gmail.com>
>> wrote:
>>>>>
>>>>> actually just as another fyi, Harbs pointed out some intriguing
>> goog
>>>>> methods recently - I don't have an immediate reference to it
>> sorry. One
>>>> of
>>>>> those seemed to allow for access to renamed names by wrapping the
>>>> original
>>>>> names in a 'magic' method that presumably GCC recognises (but
>> presumably
>>>>> returns the name unchanged in debug mode)
>>>>>
>>>>>
>>>>> On Thu, Jan 16, 2020 at 12:33 PM Greg Dove <gr...@gmail.com>
>> wrote:
>>>>>
>>>>>> 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 <
>>>> joshtynjala@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%7Cf0a04642179249d9c7a708d79ad0acda%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148093358429149&sdata=zb90%2FYNZYETbGg9liYF8BQpZxEvTOJfxEXFs9wtRkU0%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%7Cf0a04642179249d9c7a708d79ad0acda%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148093358429149&sdata=pHxyW3fxzIz8JfuD0WrvFKlE9JezSky7NSQQeYWr7QA%3D&reserved=0
>>>
>>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
>>
>>
>
>
Re: MXML and warn-public vars
Posted by Harbs <ha...@gmail.com>.
Uh. No.
You’d see data = [function, 1, ‘publicVar', true, 'value’]
It’s a function call which returns the fed parameter.
> On Jan 17, 2020, at 12:06 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> And so when I have to debug the structure in js-debug, I will see
>
> data = [function, 1, function, true, 'value']
>
> And have no idea what property is being set? I'm not in favor of this change.
>
> The public var warning is not just for MXML. It is for any dynamic access by property name whether from web services, remote object or bracket access or any other user code. Seems like we should just find a way to prevent renaming of public vars. We should be able to feed some names to the Closure renaming pass.
>
> My 2 cents,
> -Alex
>
>
> On 1/16/20, 1:51 PM, "Josh Tynjala" <jo...@bowlerhat.dev> wrote:
>
> Before:
>
> var data = [
> Component,
> 1,
> 'publicVar',
> true,
> 'value'
> ]
>
> After (debug):
>
> var data = [
> Component,
> 1,
> goog.reflect.objectProperty('publicVar'),
> true,
> 'value'
> ]
>
> In a release build, Closure compiler replaces the function call completely
> with the minified name, so it ends up being like this:
>
> var data = [
> Component,
> 1,
> '<minified name here>',
> true,
> 'value'
> ]
>
> --
> Josh Tynjala
> Bowler Hat LLC <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C69086e1d529243bf84b908d79ace4111%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148082959628228&sdata=tUWsmMHuRZZKEDGp%2BZJ9PuVWzjPLKfIDdAXcPc9o1Oo%3D&reserved=0>
>
>
> On Thu, Jan 16, 2020 at 1:38 PM Alex Harui <ah...@adobe.com.invalid> wrote:
>
>> Where does the goog.reflect.objectProperty appear in the output? In the
>> data stream?
>>
>>
>> On 1/16/20, 1:35 PM, "Harbs" <ha...@gmail.com> wrote:
>>
>> Amazing!
>>
>>> On Jan 16, 2020, at 10:59 PM, Josh Tynjala <
>> joshtynjala@bowlerhat.dev> wrote:
>>>
>>> Thank you, Harbs! Wrapping the variable name in a
>>> goog.reflect.objectProperty() call works perfectly. This is exactly
>> why I
>>> started this thread, to see if anyone could suggest possible
>> alternatives.
>>>
>>> Thankfully, we can keep the same simple data structure as before,
>> and my
>>> initial proposal with functions can be forgotten. In a release
>> build, I can
>>> see that goog.reflect.objectProperty() calls are replaced by a simple
>>> string literal (containing the minified variable name), so we don't
>> have to
>>> worry about extra performance impact.
>>>
>>> --
>>> Josh Tynjala
>>> Bowler Hat LLC <
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C69086e1d529243bf84b908d79ace4111%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148082959628228&sdata=tUWsmMHuRZZKEDGp%2BZJ9PuVWzjPLKfIDdAXcPc9o1Oo%3D&reserved=0
>>>
>>>
>>>
>>> On Wed, Jan 15, 2020 at 8:32 PM Harbs <ha...@gmail.com> wrote:
>>>
>>>> Sounds good!
>>>>
>>>>
>>>>
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FType-Based-Property-Renaming&data=02%7C01%7Caharui%40adobe.com%7C69086e1d529243bf84b908d79ace4111%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148082959638221&sdata=ktbXwvC4JX8kZWLaK0RA%2FV4fUS537QB88626q4YtHiI%3D&reserved=0
>>>> <
>>>>
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FType-Based-Property-Renaming&data=02%7C01%7Caharui%40adobe.com%7C69086e1d529243bf84b908d79ace4111%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148082959638221&sdata=ktbXwvC4JX8kZWLaK0RA%2FV4fUS537QB88626q4YtHiI%3D&reserved=0
>>>>>
>>>>
>>>> The function seems to be goog.reflect.objectProperty()
>>>>
>>>> I’m not sure exactly how it works though.
>>>>
>>>>> On Jan 16, 2020, at 1:37 AM, Greg Dove <gr...@gmail.com>
>> wrote:
>>>>>
>>>>> actually just as another fyi, Harbs pointed out some intriguing
>> goog
>>>>> methods recently - I don't have an immediate reference to it
>> sorry. One
>>>> of
>>>>> those seemed to allow for access to renamed names by wrapping the
>>>> original
>>>>> names in a 'magic' method that presumably GCC recognises (but
>> presumably
>>>>> returns the name unchanged in debug mode)
>>>>>
>>>>>
>>>>> On Thu, Jan 16, 2020 at 12:33 PM Greg Dove <gr...@gmail.com>
>> wrote:
>>>>>
>>>>>> 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 <
>>>> joshtynjala@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%7C69086e1d529243bf84b908d79ace4111%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148082959638221&sdata=AgbCdl3kMpg4tf0zzEFVuiV7jQEQgXsKnG5bb65Xf5w%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%7C69086e1d529243bf84b908d79ace4111%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148082959638221&sdata=fbojBxatX98bdzRhPzXS6P3%2BqU6n7wKg4s3Rw2MhlKo%3D&reserved=0
>>>
>>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
>>
>>
>
>
Re: MXML and warn-public vars
Posted by Josh Tynjala <jo...@bowlerhat.dev>.
Even if we find a way to prevent renaming, some people are going to want to
keep renaming enabled to minimize the size of their generated JS. In that
situation, goog.reflect.objectProperty() will still be necessary. With that
in mind, it may not be the full solution, but it's one step closer.
--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>
On Thu, Jan 16, 2020 at 2:06 PM Alex Harui <ah...@adobe.com.invalid> wrote:
> And so when I have to debug the structure in js-debug, I will see
>
> data = [function, 1, function, true, 'value']
>
> And have no idea what property is being set? I'm not in favor of this
> change.
>
> The public var warning is not just for MXML. It is for any dynamic access
> by property name whether from web services, remote object or bracket access
> or any other user code. Seems like we should just find a way to prevent
> renaming of public vars. We should be able to feed some names to the
> Closure renaming pass.
>
> My 2 cents,
> -Alex
>
>
> On 1/16/20, 1:51 PM, "Josh Tynjala" <jo...@bowlerhat.dev> wrote:
>
> Before:
>
> var data = [
> Component,
> 1,
> 'publicVar',
> true,
> 'value'
> ]
>
> After (debug):
>
> var data = [
> Component,
> 1,
> goog.reflect.objectProperty('publicVar'),
> true,
> 'value'
> ]
>
> In a release build, Closure compiler replaces the function call
> completely
> with the minified name, so it ends up being like this:
>
> var data = [
> Component,
> 1,
> '<minified name here>',
> true,
> 'value'
> ]
>
> --
> Josh Tynjala
> Bowler Hat LLC <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C69086e1d529243bf84b908d79ace4111%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148082959628228&sdata=tUWsmMHuRZZKEDGp%2BZJ9PuVWzjPLKfIDdAXcPc9o1Oo%3D&reserved=0
> >
>
>
> On Thu, Jan 16, 2020 at 1:38 PM Alex Harui <ah...@adobe.com.invalid>
> wrote:
>
> > Where does the goog.reflect.objectProperty appear in the output?
> In the
> > data stream?
> >
> >
> > On 1/16/20, 1:35 PM, "Harbs" <ha...@gmail.com> wrote:
> >
> > Amazing!
> >
> > > On Jan 16, 2020, at 10:59 PM, Josh Tynjala <
> > joshtynjala@bowlerhat.dev> wrote:
> > >
> > > Thank you, Harbs! Wrapping the variable name in a
> > > goog.reflect.objectProperty() call works perfectly. This is
> exactly
> > why I
> > > started this thread, to see if anyone could suggest possible
> > alternatives.
> > >
> > > Thankfully, we can keep the same simple data structure as
> before,
> > and my
> > > initial proposal with functions can be forgotten. In a release
> > build, I can
> > > see that goog.reflect.objectProperty() calls are replaced by a
> simple
> > > string literal (containing the minified variable name), so we
> don't
> > have to
> > > worry about extra performance impact.
> > >
> > > --
> > > Josh Tynjala
> > > Bowler Hat LLC <
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C69086e1d529243bf84b908d79ace4111%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148082959628228&sdata=tUWsmMHuRZZKEDGp%2BZJ9PuVWzjPLKfIDdAXcPc9o1Oo%3D&reserved=0
> > >
> > >
> > >
> > > On Wed, Jan 15, 2020 at 8:32 PM Harbs <ha...@gmail.com>
> wrote:
> > >
> > >> Sounds good!
> > >>
> > >>
> > >>
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FType-Based-Property-Renaming&data=02%7C01%7Caharui%40adobe.com%7C69086e1d529243bf84b908d79ace4111%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148082959638221&sdata=ktbXwvC4JX8kZWLaK0RA%2FV4fUS537QB88626q4YtHiI%3D&reserved=0
> > >> <
> > >>
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FType-Based-Property-Renaming&data=02%7C01%7Caharui%40adobe.com%7C69086e1d529243bf84b908d79ace4111%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148082959638221&sdata=ktbXwvC4JX8kZWLaK0RA%2FV4fUS537QB88626q4YtHiI%3D&reserved=0
> > >>>
> > >>
> > >> The function seems to be goog.reflect.objectProperty()
> > >>
> > >> I’m not sure exactly how it works though.
> > >>
> > >>> On Jan 16, 2020, at 1:37 AM, Greg Dove <gr...@gmail.com>
> > wrote:
> > >>>
> > >>> actually just as another fyi, Harbs pointed out some
> intriguing
> > goog
> > >>> methods recently - I don't have an immediate reference to it
> > sorry. One
> > >> of
> > >>> those seemed to allow for access to renamed names by
> wrapping the
> > >> original
> > >>> names in a 'magic' method that presumably GCC recognises (but
> > presumably
> > >>> returns the name unchanged in debug mode)
> > >>>
> > >>>
> > >>> On Thu, Jan 16, 2020 at 12:33 PM Greg Dove <
> greg.dove@gmail.com>
> > wrote:
> > >>>
> > >>>> 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 <
> > >> joshtynjala@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%7C69086e1d529243bf84b908d79ace4111%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148082959638221&sdata=AgbCdl3kMpg4tf0zzEFVuiV7jQEQgXsKnG5bb65Xf5w%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%7C69086e1d529243bf84b908d79ace4111%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148082959638221&sdata=fbojBxatX98bdzRhPzXS6P3%2BqU6n7wKg4s3Rw2MhlKo%3D&reserved=0
> > >
> > >>>>>
> > >>>>
> > >>
> > >>
> >
> >
> >
> >
>
>
>
Re: MXML and warn-public vars
Posted by Alex Harui <ah...@adobe.com.INVALID>.
And so when I have to debug the structure in js-debug, I will see
data = [function, 1, function, true, 'value']
And have no idea what property is being set? I'm not in favor of this change.
The public var warning is not just for MXML. It is for any dynamic access by property name whether from web services, remote object or bracket access or any other user code. Seems like we should just find a way to prevent renaming of public vars. We should be able to feed some names to the Closure renaming pass.
My 2 cents,
-Alex
On 1/16/20, 1:51 PM, "Josh Tynjala" <jo...@bowlerhat.dev> wrote:
Before:
var data = [
Component,
1,
'publicVar',
true,
'value'
]
After (debug):
var data = [
Component,
1,
goog.reflect.objectProperty('publicVar'),
true,
'value'
]
In a release build, Closure compiler replaces the function call completely
with the minified name, so it ends up being like this:
var data = [
Component,
1,
'<minified name here>',
true,
'value'
]
--
Josh Tynjala
Bowler Hat LLC <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C69086e1d529243bf84b908d79ace4111%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148082959628228&sdata=tUWsmMHuRZZKEDGp%2BZJ9PuVWzjPLKfIDdAXcPc9o1Oo%3D&reserved=0>
On Thu, Jan 16, 2020 at 1:38 PM Alex Harui <ah...@adobe.com.invalid> wrote:
> Where does the goog.reflect.objectProperty appear in the output? In the
> data stream?
>
>
> On 1/16/20, 1:35 PM, "Harbs" <ha...@gmail.com> wrote:
>
> Amazing!
>
> > On Jan 16, 2020, at 10:59 PM, Josh Tynjala <
> joshtynjala@bowlerhat.dev> wrote:
> >
> > Thank you, Harbs! Wrapping the variable name in a
> > goog.reflect.objectProperty() call works perfectly. This is exactly
> why I
> > started this thread, to see if anyone could suggest possible
> alternatives.
> >
> > Thankfully, we can keep the same simple data structure as before,
> and my
> > initial proposal with functions can be forgotten. In a release
> build, I can
> > see that goog.reflect.objectProperty() calls are replaced by a simple
> > string literal (containing the minified variable name), so we don't
> have to
> > worry about extra performance impact.
> >
> > --
> > Josh Tynjala
> > Bowler Hat LLC <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C69086e1d529243bf84b908d79ace4111%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148082959628228&sdata=tUWsmMHuRZZKEDGp%2BZJ9PuVWzjPLKfIDdAXcPc9o1Oo%3D&reserved=0
> >
> >
> >
> > On Wed, Jan 15, 2020 at 8:32 PM Harbs <ha...@gmail.com> wrote:
> >
> >> Sounds good!
> >>
> >>
> >>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FType-Based-Property-Renaming&data=02%7C01%7Caharui%40adobe.com%7C69086e1d529243bf84b908d79ace4111%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148082959638221&sdata=ktbXwvC4JX8kZWLaK0RA%2FV4fUS537QB88626q4YtHiI%3D&reserved=0
> >> <
> >>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FType-Based-Property-Renaming&data=02%7C01%7Caharui%40adobe.com%7C69086e1d529243bf84b908d79ace4111%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148082959638221&sdata=ktbXwvC4JX8kZWLaK0RA%2FV4fUS537QB88626q4YtHiI%3D&reserved=0
> >>>
> >>
> >> The function seems to be goog.reflect.objectProperty()
> >>
> >> I’m not sure exactly how it works though.
> >>
> >>> On Jan 16, 2020, at 1:37 AM, Greg Dove <gr...@gmail.com>
> wrote:
> >>>
> >>> actually just as another fyi, Harbs pointed out some intriguing
> goog
> >>> methods recently - I don't have an immediate reference to it
> sorry. One
> >> of
> >>> those seemed to allow for access to renamed names by wrapping the
> >> original
> >>> names in a 'magic' method that presumably GCC recognises (but
> presumably
> >>> returns the name unchanged in debug mode)
> >>>
> >>>
> >>> On Thu, Jan 16, 2020 at 12:33 PM Greg Dove <gr...@gmail.com>
> wrote:
> >>>
> >>>> 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 <
> >> joshtynjala@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%7C69086e1d529243bf84b908d79ace4111%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148082959638221&sdata=AgbCdl3kMpg4tf0zzEFVuiV7jQEQgXsKnG5bb65Xf5w%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%7C69086e1d529243bf84b908d79ace4111%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148082959638221&sdata=fbojBxatX98bdzRhPzXS6P3%2BqU6n7wKg4s3Rw2MhlKo%3D&reserved=0
> >
> >>>>>
> >>>>
> >>
> >>
>
>
>
>
Re: MXML and warn-public vars
Posted by Josh Tynjala <jo...@bowlerhat.dev>.
Before:
var data = [
Component,
1,
'publicVar',
true,
'value'
]
After (debug):
var data = [
Component,
1,
goog.reflect.objectProperty('publicVar'),
true,
'value'
]
In a release build, Closure compiler replaces the function call completely
with the minified name, so it ends up being like this:
var data = [
Component,
1,
'<minified name here>',
true,
'value'
]
--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>
On Thu, Jan 16, 2020 at 1:38 PM Alex Harui <ah...@adobe.com.invalid> wrote:
> Where does the goog.reflect.objectProperty appear in the output? In the
> data stream?
>
>
> On 1/16/20, 1:35 PM, "Harbs" <ha...@gmail.com> wrote:
>
> Amazing!
>
> > On Jan 16, 2020, at 10:59 PM, Josh Tynjala <
> joshtynjala@bowlerhat.dev> wrote:
> >
> > Thank you, Harbs! Wrapping the variable name in a
> > goog.reflect.objectProperty() call works perfectly. This is exactly
> why I
> > started this thread, to see if anyone could suggest possible
> alternatives.
> >
> > Thankfully, we can keep the same simple data structure as before,
> and my
> > initial proposal with functions can be forgotten. In a release
> build, I can
> > see that goog.reflect.objectProperty() calls are replaced by a simple
> > string literal (containing the minified variable name), so we don't
> have to
> > worry about extra performance impact.
> >
> > --
> > Josh Tynjala
> > Bowler Hat LLC <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C6989d0c95b5d446ca0a208d79acbef36%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148072995391870&sdata=c33xVrJb%2BPoqPWLgcvcpmyVjO8TYBKzJkNhz1NisDpw%3D&reserved=0
> >
> >
> >
> > On Wed, Jan 15, 2020 at 8:32 PM Harbs <ha...@gmail.com> wrote:
> >
> >> Sounds good!
> >>
> >>
> >>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FType-Based-Property-Renaming&data=02%7C01%7Caharui%40adobe.com%7C6989d0c95b5d446ca0a208d79acbef36%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148072995391870&sdata=EqoLXGt8acxKifq31XQv%2F61ClzyLEvj%2Ft5OdyBmmTd8%3D&reserved=0
> >> <
> >>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FType-Based-Property-Renaming&data=02%7C01%7Caharui%40adobe.com%7C6989d0c95b5d446ca0a208d79acbef36%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148072995391870&sdata=EqoLXGt8acxKifq31XQv%2F61ClzyLEvj%2Ft5OdyBmmTd8%3D&reserved=0
> >>>
> >>
> >> The function seems to be goog.reflect.objectProperty()
> >>
> >> I’m not sure exactly how it works though.
> >>
> >>> On Jan 16, 2020, at 1:37 AM, Greg Dove <gr...@gmail.com>
> wrote:
> >>>
> >>> actually just as another fyi, Harbs pointed out some intriguing
> goog
> >>> methods recently - I don't have an immediate reference to it
> sorry. One
> >> of
> >>> those seemed to allow for access to renamed names by wrapping the
> >> original
> >>> names in a 'magic' method that presumably GCC recognises (but
> presumably
> >>> returns the name unchanged in debug mode)
> >>>
> >>>
> >>> On Thu, Jan 16, 2020 at 12:33 PM Greg Dove <gr...@gmail.com>
> wrote:
> >>>
> >>>> 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 <
> >> joshtynjala@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%7C6989d0c95b5d446ca0a208d79acbef36%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148072995391870&sdata=uQr3CVQajRPhW%2BQApIyV72o7PUziIHRKMtlNnI7eiiU%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%7C6989d0c95b5d446ca0a208d79acbef36%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148072995391870&sdata=c33xVrJb%2BPoqPWLgcvcpmyVjO8TYBKzJkNhz1NisDpw%3D&reserved=0
> >
> >>>>>
> >>>>
> >>
> >>
>
>
>
>
Re: MXML and warn-public vars
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Where does the goog.reflect.objectProperty appear in the output? In the data stream?
On 1/16/20, 1:35 PM, "Harbs" <ha...@gmail.com> wrote:
Amazing!
> On Jan 16, 2020, at 10:59 PM, Josh Tynjala <jo...@bowlerhat.dev> wrote:
>
> Thank you, Harbs! Wrapping the variable name in a
> goog.reflect.objectProperty() call works perfectly. This is exactly why I
> started this thread, to see if anyone could suggest possible alternatives.
>
> Thankfully, we can keep the same simple data structure as before, and my
> initial proposal with functions can be forgotten. In a release build, I can
> see that goog.reflect.objectProperty() calls are replaced by a simple
> string literal (containing the minified variable name), so we don't have to
> worry about extra performance impact.
>
> --
> Josh Tynjala
> Bowler Hat LLC <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C6989d0c95b5d446ca0a208d79acbef36%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148072995391870&sdata=c33xVrJb%2BPoqPWLgcvcpmyVjO8TYBKzJkNhz1NisDpw%3D&reserved=0>
>
>
> On Wed, Jan 15, 2020 at 8:32 PM Harbs <ha...@gmail.com> wrote:
>
>> Sounds good!
>>
>>
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FType-Based-Property-Renaming&data=02%7C01%7Caharui%40adobe.com%7C6989d0c95b5d446ca0a208d79acbef36%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148072995391870&sdata=EqoLXGt8acxKifq31XQv%2F61ClzyLEvj%2Ft5OdyBmmTd8%3D&reserved=0
>> <
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FType-Based-Property-Renaming&data=02%7C01%7Caharui%40adobe.com%7C6989d0c95b5d446ca0a208d79acbef36%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148072995391870&sdata=EqoLXGt8acxKifq31XQv%2F61ClzyLEvj%2Ft5OdyBmmTd8%3D&reserved=0
>>>
>>
>> The function seems to be goog.reflect.objectProperty()
>>
>> I’m not sure exactly how it works though.
>>
>>> On Jan 16, 2020, at 1:37 AM, Greg Dove <gr...@gmail.com> wrote:
>>>
>>> actually just as another fyi, Harbs pointed out some intriguing goog
>>> methods recently - I don't have an immediate reference to it sorry. One
>> of
>>> those seemed to allow for access to renamed names by wrapping the
>> original
>>> names in a 'magic' method that presumably GCC recognises (but presumably
>>> returns the name unchanged in debug mode)
>>>
>>>
>>> On Thu, Jan 16, 2020 at 12:33 PM Greg Dove <gr...@gmail.com> wrote:
>>>
>>>> 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 <
>> joshtynjala@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%7C6989d0c95b5d446ca0a208d79acbef36%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148072995391870&sdata=uQr3CVQajRPhW%2BQApIyV72o7PUziIHRKMtlNnI7eiiU%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%7C6989d0c95b5d446ca0a208d79acbef36%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148072995391870&sdata=c33xVrJb%2BPoqPWLgcvcpmyVjO8TYBKzJkNhz1NisDpw%3D&reserved=0>
>>>>>
>>>>
>>
>>
Re: MXML and warn-public vars
Posted by Harbs <ha...@gmail.com>.
Amazing!
> On Jan 16, 2020, at 10:59 PM, Josh Tynjala <jo...@bowlerhat.dev> wrote:
>
> Thank you, Harbs! Wrapping the variable name in a
> goog.reflect.objectProperty() call works perfectly. This is exactly why I
> started this thread, to see if anyone could suggest possible alternatives.
>
> Thankfully, we can keep the same simple data structure as before, and my
> initial proposal with functions can be forgotten. In a release build, I can
> see that goog.reflect.objectProperty() calls are replaced by a simple
> string literal (containing the minified variable name), so we don't have to
> worry about extra performance impact.
>
> --
> Josh Tynjala
> Bowler Hat LLC <https://bowlerhat.dev>
>
>
> On Wed, Jan 15, 2020 at 8:32 PM Harbs <ha...@gmail.com> wrote:
>
>> Sounds good!
>>
>>
>> https://github.com/google/closure-compiler/wiki/Type-Based-Property-Renaming
>> <
>> https://github.com/google/closure-compiler/wiki/Type-Based-Property-Renaming
>>>
>>
>> The function seems to be goog.reflect.objectProperty()
>>
>> I’m not sure exactly how it works though.
>>
>>> On Jan 16, 2020, at 1:37 AM, Greg Dove <gr...@gmail.com> wrote:
>>>
>>> actually just as another fyi, Harbs pointed out some intriguing goog
>>> methods recently - I don't have an immediate reference to it sorry. One
>> of
>>> those seemed to allow for access to renamed names by wrapping the
>> original
>>> names in a 'magic' method that presumably GCC recognises (but presumably
>>> returns the name unchanged in debug mode)
>>>
>>>
>>> On Thu, Jan 16, 2020 at 12:33 PM Greg Dove <gr...@gmail.com> wrote:
>>>
>>>> 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 <
>> joshtynjala@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>
>>>>>
>>>>
>>
>>
Re: MXML and warn-public vars
Posted by Josh Tynjala <jo...@bowlerhat.dev>.
Thank you, Harbs! Wrapping the variable name in a
goog.reflect.objectProperty() call works perfectly. This is exactly why I
started this thread, to see if anyone could suggest possible alternatives.
Thankfully, we can keep the same simple data structure as before, and my
initial proposal with functions can be forgotten. In a release build, I can
see that goog.reflect.objectProperty() calls are replaced by a simple
string literal (containing the minified variable name), so we don't have to
worry about extra performance impact.
--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>
On Wed, Jan 15, 2020 at 8:32 PM Harbs <ha...@gmail.com> wrote:
> Sounds good!
>
>
> https://github.com/google/closure-compiler/wiki/Type-Based-Property-Renaming
> <
> https://github.com/google/closure-compiler/wiki/Type-Based-Property-Renaming
> >
>
> The function seems to be goog.reflect.objectProperty()
>
> I’m not sure exactly how it works though.
>
> > On Jan 16, 2020, at 1:37 AM, Greg Dove <gr...@gmail.com> wrote:
> >
> > actually just as another fyi, Harbs pointed out some intriguing goog
> > methods recently - I don't have an immediate reference to it sorry. One
> of
> > those seemed to allow for access to renamed names by wrapping the
> original
> > names in a 'magic' method that presumably GCC recognises (but presumably
> > returns the name unchanged in debug mode)
> >
> >
> > On Thu, Jan 16, 2020 at 12:33 PM Greg Dove <gr...@gmail.com> wrote:
> >
> >> 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 <
> joshtynjala@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>
> >>>
> >>
>
>
Re: MXML and warn-public vars
Posted by Harbs <ha...@gmail.com>.
FWIW, all the functions in goog.reflect are worthy of a look.
> On Jan 16, 2020, at 6:32 AM, Harbs <ha...@gmail.com> wrote:
>
> Sounds good!
>
> https://github.com/google/closure-compiler/wiki/Type-Based-Property-Renaming <https://github.com/google/closure-compiler/wiki/Type-Based-Property-Renaming>
>
> The function seems to be goog.reflect.objectProperty()
>
> I’m not sure exactly how it works though.
>
>> On Jan 16, 2020, at 1:37 AM, Greg Dove <greg.dove@gmail.com <ma...@gmail.com>> wrote:
>>
>> actually just as another fyi, Harbs pointed out some intriguing goog
>> methods recently - I don't have an immediate reference to it sorry. One of
>> those seemed to allow for access to renamed names by wrapping the original
>> names in a 'magic' method that presumably GCC recognises (but presumably
>> returns the name unchanged in debug mode)
>>
>>
>> On Thu, Jan 16, 2020 at 12:33 PM Greg Dove <greg.dove@gmail.com <ma...@gmail.com>> wrote:
>>
>>> 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 <joshtynjala@bowlerhat.dev <ma...@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 <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>
>>>>
>>>
>
Re: MXML and warn-public vars
Posted by Harbs <ha...@gmail.com>.
Sounds good!
https://github.com/google/closure-compiler/wiki/Type-Based-Property-Renaming <https://github.com/google/closure-compiler/wiki/Type-Based-Property-Renaming>
The function seems to be goog.reflect.objectProperty()
I’m not sure exactly how it works though.
> On Jan 16, 2020, at 1:37 AM, Greg Dove <gr...@gmail.com> wrote:
>
> actually just as another fyi, Harbs pointed out some intriguing goog
> methods recently - I don't have an immediate reference to it sorry. One of
> those seemed to allow for access to renamed names by wrapping the original
> names in a 'magic' method that presumably GCC recognises (but presumably
> returns the name unchanged in debug mode)
>
>
> On Thu, Jan 16, 2020 at 12:33 PM Greg Dove <gr...@gmail.com> wrote:
>
>> 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 <jo...@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>
>>>
>>
Re: MXML and warn-public vars
Posted by Greg Dove <gr...@gmail.com>.
actually just as another fyi, Harbs pointed out some intriguing goog
methods recently - I don't have an immediate reference to it sorry. One of
those seemed to allow for access to renamed names by wrapping the original
names in a 'magic' method that presumably GCC recognises (but presumably
returns the name unchanged in debug mode)
On Thu, Jan 16, 2020 at 12:33 PM Greg Dove <gr...@gmail.com> wrote:
> 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 <jo...@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>
>>
>
Re: MXML and warn-public vars
Posted by Greg Dove <gr...@gmail.com>.
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 <jo...@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>
>