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 <[email protected]> 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" <[email protected]> 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&amp;data=02%7C01%7Caharui%40adobe.com%7C69086e1d529243bf84b908d79ace4111%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148082959628228&amp;sdata=tUWsmMHuRZZKEDGp%2BZJ9PuVWzjPLKfIDdAXcPc9o1Oo%3D&amp;reserved=0>
> 
> 
>    On Thu, Jan 16, 2020 at 1:38 PM Alex Harui <[email protected]> 
> wrote:
> 
>> Where does the  goog.reflect.objectProperty appear in the output?  In the
>> data stream?
>> 
>> 
>> On 1/16/20, 1:35 PM, "Harbs" <[email protected]> wrote:
>> 
>>    Amazing!
>> 
>>> On Jan 16, 2020, at 10:59 PM, Josh Tynjala <
>> [email protected]> 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&amp;data=02%7C01%7Caharui%40adobe.com%7C69086e1d529243bf84b908d79ace4111%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148082959628228&amp;sdata=tUWsmMHuRZZKEDGp%2BZJ9PuVWzjPLKfIDdAXcPc9o1Oo%3D&amp;reserved=0
>>> 
>>> 
>>> 
>>> On Wed, Jan 15, 2020 at 8:32 PM Harbs <[email protected]> wrote:
>>> 
>>>> Sounds good!
>>>> 
>>>> 
>>>> 
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FType-Based-Property-Renaming&amp;data=02%7C01%7Caharui%40adobe.com%7C69086e1d529243bf84b908d79ace4111%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148082959638221&amp;sdata=ktbXwvC4JX8kZWLaK0RA%2FV4fUS537QB88626q4YtHiI%3D&amp;reserved=0
>>>> <
>>>> 
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FType-Based-Property-Renaming&amp;data=02%7C01%7Caharui%40adobe.com%7C69086e1d529243bf84b908d79ace4111%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148082959638221&amp;sdata=ktbXwvC4JX8kZWLaK0RA%2FV4fUS537QB88626q4YtHiI%3D&amp;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 <[email protected]>
>> 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 <[email protected]>
>> 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 <
>>>> [email protected]>
>>>>>> wrote:
>>>>>> 
>>>>>>> According to the commit linked below, the -warn-public-vars
>> compiler
>>>>>>> option
>>>>>>> was added because setting a public var in MXML does not
>> currently work
>>>>>>> properly in a release build.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>> 
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-compiler%2Fcommit%2Feed5882ba935870a98ba4fe8cbf499e5d8344f60&amp;data=02%7C01%7Caharui%40adobe.com%7C69086e1d529243bf84b908d79ace4111%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148082959638221&amp;sdata=AgbCdl3kMpg4tf0zzEFVuiV7jQEQgXsKnG5bb65Xf5w%3D&amp;reserved=0
>>>>>>> 
>>>>>>> In other words, this MXML code won't work if it's a public
>> variable and
>>>>>>> not
>>>>>>> a setter:
>>>>>>> 
>>>>>>> <Component publicVar="value"/>
>>>>>>> 
>>>>>>> For reference, the compiler currently writes the name of the
>> public
>>>>>>> variable as a string to the generated JS, like this:
>>>>>>> 
>>>>>>> var data = [
>>>>>>> Component,
>>>>>>>  1,
>>>>>>>  'publicVar',
>>>>>>>  true,
>>>>>>>  'value'
>>>>>>> ]
>>>>>>> 
>>>>>>> At runtime, it interprets this array of properties, and
>> basically runs
>>>>>>> code
>>>>>>> like this:
>>>>>>> 
>>>>>>> comp['publicVar'] = 'value';
>>>>>>> 
>>>>>>> Since Closure compiler rewrites variable names during the
>> minification
>>>>>>> process, this code keeps using the original name, but other code
>> in the
>>>>>>> app
>>>>>>> might start looking for a shorter variable name like "uB". This
>> is the
>>>>>>> failure that we're warning about.
>>>>>>> 
>>>>>>> I propose updating the code generated by the compiler to
>> something like
>>>>>>> this instead:
>>>>>>> 
>>>>>>> var data = [
>>>>>>>  Component,
>>>>>>>  1,
>>>>>>>  function(){ this.publicVar=true }
>>>>>>> ]
>>>>>>> 
>>>>>>> At runtime, the class that interprets MXML data will detect the
>>>> function
>>>>>>> and call it like this:
>>>>>>> 
>>>>>>> func.apply(comp);
>>>>>>> 
>>>>>>> Because this new code will no longer use a string, Closure can
>> rewrite
>>>> the
>>>>>>> property name with its minified version, just like in other
>> parts of
>>>> the
>>>>>>> app, and we'll no longer need to warn on declarations of public
>>>> variables.
>>>>>>> 
>>>>>>> I have a working prototype for primitive values, like String,
>> Boolean,
>>>> and
>>>>>>> Number. Objects and Arrays follow a different path in the MXML
>> data
>>>>>>> interpreter, but I don't see why I wouldn't be able to handle
>> those
>>>> with a
>>>>>>> similar approach.
>>>>>>> 
>>>>>>> Thoughts?
>>>>>>> 
>>>>>>> --
>>>>>>> Josh Tynjala
>>>>>>> Bowler Hat LLC <
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&amp;data=02%7C01%7Caharui%40adobe.com%7C69086e1d529243bf84b908d79ace4111%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637148082959638221&amp;sdata=fbojBxatX98bdzRhPzXS6P3%2BqU6n7wKg4s3Rw2MhlKo%3D&amp;reserved=0
>>> 
>>>>>>> 
>>>>>> 
>>>> 
>>>> 
>> 
>> 
>> 
>> 
> 
> 

Reply via email to