Hi Josh, many thanks for this report to see what changed:
Although all is impressive, I think the second point is really important, if is what I think it's. >From always, I had "false compilations" in TDJ (and other real apps) that make string labels in menus, list, and icons, be blank sometimes and randomly. I think is 1/20 compilations. So that change seems to fix that if I'm understanding correctly. I'll be watching that the following days to see if that's finally solved or I still can get a false compilation. If is solved, I think this change is key, since until now I think an user getting that behaviour will think not so well about Royale stability. Thanks!! :) Carlos El mié., 1 abr. 2020 a las 21:04, Josh Tynjala (<joshtynj...@bowlerhat.dev>) escribió: > Good news! I was able to expand on what Alex suggested to provide a > solution that prevents public variables from being renamed by Google > Closure in release builds. A few key points: > > - You can set public variables in MXML, and they will work correctly in > release builds. Previously, only properties with setters worked in > release > builds. > - I've also determined how to prevent Google Closure from creating > multiple copies of static public variables, which caused some values > (numbers, boolean, strings) to get out of sync if changed at runtime. > This > was a closely related issue. > - I added prevent-rename-public-symbols and > prevent-rename-protected-symbols compiler options. They are true by > default, but you can set them to false to go back to the old behavior > (which would include reporting a warning for public vars). > - No changes were required to the MXMLDescriptor, so my changes won't > mess with debugging workflows that require inspecting that data > structure > at runtime. > > The process of implementing a better solution for this gave me some ideas > related to adding more control over exports, so I plan to give that another > try too. Thanks again to Alex for the suggestions that helped make this > happen. > > -- > Josh Tynjala > Bowler Hat LLC <https://bowlerhat.dev> > > > On Mon, Mar 30, 2020 at 10:48 AM Josh Tynjala <joshtynj...@bowlerhat.dev> > wrote: > > > 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 <joshtynj...@bowlerhat.dev> > > 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 <aha...@adobe.com.invalid> > >> wrote: > >> > >>> > >>> > >>> On 3/26/20, 12:23 PM, "Josh Tynjala" <joshtynj...@bowlerhat.dev> > 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 > >>> > >>> > >>> > -- Carlos Rovira http://about.me/carlosrovira
