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://bowlerhat.dev>
>
>
> On Wed, Jan 15, 2020 at 8:32 PM Harbs <[email protected]> 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 <[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://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>
>>>>>
>>>>
>>
>>
