FWIW, all the functions in goog.reflect are worthy of a look.
> On Jan 16, 2020, at 6:32 AM, Harbs <harbs.li...@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.d...@gmail.com
>> <mailto: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
>> <mailto: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
>>> <mailto: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://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>
>>>>
>>>
>
