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 > > >
