I did a quick test, and I can confirm that a public variable will not be
renamed if a public getter with the same name exists on a different class.

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Thu, Mar 26, 2020 at 1:03 PM Josh Tynjala <[email protected]>
wrote:

> Thanks for the info about Object.defineProperties(). That could be a way
> to provide a workaround that doesn't mess too much with other stuff.
>
> --
> Josh Tynjala
> Bowler Hat LLC <https://bowlerhat.dev>
>
>
> On Thu, Mar 26, 2020 at 12:45 PM Alex Harui <[email protected]>
> wrote:
>
>>
>>
>> On 3/26/20, 12:23 PM, "Josh Tynjala" <[email protected]> wrote:
>>
>>     We can walk the AST if we have the source code. However, if an MXML
>> class
>>     gets compiled into a SWC, I don't think there's a way to figure out
>> which
>>     properties are being set in MXML from the definitions alone. When I
>> was
>>     investigating some things, I tried the AST walk until I realized that
>> it
>>     only worked in my app project, and not with the classes that I was
>> using
>>     from framework SWCs.
>>
>> One possibility is that the compiler scans every JS file and looks for
>> the MXMLDescriptor and scans it for strings.  Also have to look for the
>> properties array as well.
>>
>>     I might actually end up looking at adding an option to convert public
>> vars
>>     into getters/setters first. Should be easier than some of the
>> alternatives,
>>     which I can dig into more later.
>>
>> FWIW, AFAICT, any Object.defineProperties structure blocks renaming
>> through the entire compilation, not just within the file being visited.  In
>> fact, I'm not even sure it has to be Object.defineProperties.  It looks
>> like there is some criteria for being a global structure.  So to me, it
>> looks like you can prevent a rename, not only by swapping in a legitimate
>> getter/setter for the public var, but also by having some global structure,
>> possibly in an Object.defineProperties attached to the app that defines a
>> bunch of empty properties on some never-to-be-used object and then Closure
>> will not rename those properties on other objects.
>>
>> Of course, I could be wrong, but that's what I think I've seen.  I think
>> I saw that including some class with a getter/setter would cause properties
>> in other classes that use the same property name to not be renamed.
>>
>> HTH,
>> -Alex
>>
>>
>>

Reply via email to