You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@royale.apache.org by Josh Tynjala <jo...@bowlerhat.dev> on 2020/04/01 19:04:31 UTC
Re: Control over export/rename: Finally giving up
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 <jo...@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 <jo...@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 <ah...@adobe.com.invalid>
>> wrote:
>>
>>>
>>>
>>> On 3/26/20, 12:23 PM, "Josh Tynjala" <jo...@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
>>>
>>>
>>>
Re: Royale compiler remove labels and/or icons randomly (was Re:
Control over export/rename: Finally giving up)
Posted by Carlos Rovira <ca...@apache.org>.
Ok Josh,
thanks. When I read your explanation I matched directly with that compiler
problem, it's a pity that not was related
Thanks
El vie., 3 abr. 2020 a las 17:58, Josh Tynjala (<jo...@bowlerhat.dev>)
escribió:
> For the record, I'm pretty sure that the change that I made was something
> completely different than what you were thinking it was.
>
> --
> Josh Tynjala
> Bowler Hat LLC <https://bowlerhat.dev>
>
>
> On Thu, Apr 2, 2020 at 4:47 PM Carlos Rovira <ca...@apache.org>
> wrote:
>
> > Hi
> >
> > I'm sorry to say that the Josh's fix I commented is not fixing the thing
> I
> > suggested. The problem of labels removed is still there as you can see in
> > the following image (I had it today again):
> >
> > https://imgur.com/a/NEiUZXH
> >
> > The labels or icons that are removed change, so I think this could be
> some
> > thread problem since happens un one compilation from around other 15 or
> > so...
> >
> > If someone could take a look at this, would be great, since I think is an
> > important problem.
> > I think we should detect what's happening if we can before 1.0
> >
> > Thanks
> >
> >
> >
> > > > On Thu, Apr 2, 2020 at 9:23 PM Carlos Rovira <
> carlosrovira@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 (<
> > > >> joshtynjala@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>
> > > >> >
> > > >> >
> > >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
> >
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Royale compiler remove labels and/or icons randomly (was Re:
Control over export/rename: Finally giving up)
Posted by Josh Tynjala <jo...@bowlerhat.dev>.
For the record, I'm pretty sure that the change that I made was something
completely different than what you were thinking it was.
--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>
On Thu, Apr 2, 2020 at 4:47 PM Carlos Rovira <ca...@apache.org>
wrote:
> Hi
>
> I'm sorry to say that the Josh's fix I commented is not fixing the thing I
> suggested. The problem of labels removed is still there as you can see in
> the following image (I had it today again):
>
> https://imgur.com/a/NEiUZXH
>
> The labels or icons that are removed change, so I think this could be some
> thread problem since happens un one compilation from around other 15 or
> so...
>
> If someone could take a look at this, would be great, since I think is an
> important problem.
> I think we should detect what's happening if we can before 1.0
>
> Thanks
>
>
>
> > > On Thu, Apr 2, 2020 at 9:23 PM Carlos Rovira <ca...@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 (<
> > >> joshtynjala@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>
> > >> >
> > >> >
> >
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
Royale compiler remove labels and/or icons randomly (was Re: Control
over export/rename: Finally giving up)
Posted by Carlos Rovira <ca...@apache.org>.
Hi
I'm sorry to say that the Josh's fix I commented is not fixing the thing I
suggested. The problem of labels removed is still there as you can see in
the following image (I had it today again):
https://imgur.com/a/NEiUZXH
The labels or icons that are removed change, so I think this could be some
thread problem since happens un one compilation from around other 15 or
so...
If someone could take a look at this, would be great, since I think is an
important problem.
I think we should detect what's happening if we can before 1.0
Thanks
> > On Thu, Apr 2, 2020 at 9:23 PM Carlos Rovira <ca...@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 (<
> >> joshtynjala@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>
> >> >
> >> >
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Control over export/rename: Finally giving up
Posted by Greg Dove <gr...@gmail.com>.
' 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 <gr...@gmail.com> 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 <ca...@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 (<
>> joshtynjala@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 <
>> joshtynjala@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 <
>> joshtynjala@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 <aharui@adobe.com.invalid
>> >
>> > >> wrote:
>> > >>
>> > >>>
>> > >>>
>> > >>> On 3/26/20, 12:23 PM, "Josh Tynjala" <jo...@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
>>
>
Re: Control over export/rename: Finally giving up
Posted by Greg Dove <gr...@gmail.com>.
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 <ca...@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 (<joshtynjala@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 <joshtynjala@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 <
> joshtynjala@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 <aharui@adobe.com.invalid
> >
> > >> wrote:
> > >>
> > >>>
> > >>>
> > >>> On 3/26/20, 12:23 PM, "Josh Tynjala" <jo...@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
>
Re: Control over export/rename: Finally giving up
Posted by Carlos Rovira <ca...@apache.org>.
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 (<jo...@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 <jo...@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 <jo...@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 <ah...@adobe.com.invalid>
> >> wrote:
> >>
> >>>
> >>>
> >>> On 3/26/20, 12:23 PM, "Josh Tynjala" <jo...@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