FWIW, I have a somewhat related fix coming hopefully in the next few hours for an issue with complex static initializers of consts or vars. The issue is that while the declarations are working better with the getter/setters at startup, the access to the var or const from other code was broken.
It needed an empty declaration against the class with the original approach (without initializers, so only really as clues for GCC) against the class - without that, the @lends directive in the Object.defineProperties declaration for the getter/setter approach was not working because it seems GCC needs the original empty definition of the static field to 'match' to with the @lends directive. On Thu, Apr 2, 2020 at 9:23 PM Carlos Rovira <carlosrov...@apache.org> wrote: > 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 >
