On 1/16/20, 2:08 PM, "Harbs" <harbs.li...@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 <aha...@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" <joshtynj...@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 <aha...@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" <harbs.li...@gmail.com> wrote:
>>
>> Amazing!
>>
>>> On Jan 16, 2020, at 10:59 PM, Josh Tynjala <
>> joshtynj...@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 <harbs.li...@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 <greg.d...@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.d...@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 <
>>>> joshtynj...@bowlerhat.dev>
>>>>>> wrote:
>>>>>>
>>>>>>> According to the commit linked below, the -warn-public-vars
>> compiler
>>>>>>> option
>>>>>>> was added because setting a public var in MXML does not
>> currently work
>>>>>>> properly in a release build.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>
>>
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-compiler%2Fcommit%2Feed5882ba935870a98ba4fe8cbf499e5d8344f60&data=02%7C01%7Caharui%40adobe.com%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
>>>
>>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
>>
>>
>
>
