' fix coming hopefully in the next few hours ' <- by which I mean I have already done it, and it works, just working through some other things.
On Thu, Apr 2, 2020 at 9:42 PM Greg Dove <[email protected]> wrote: > > 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 <[email protected]> > 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 (< >> [email protected]>) >> 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 < >> [email protected]> >> > 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 < >> [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 >> > >>> >> > >>> >> > >>> >> > >> >> >> -- >> Carlos Rovira >> http://about.me/carlosrovira >> >
