Yes, Royale is always using Falcon. -- Josh Tynjala Bowler Hat LLC <https://bowlerhat.dev>
On Tue, Nov 24, 2020 at 10:20 AM Andrew Wetmore <cottag...@gmail.com> wrote: > Do the Falcon compiler options apply if one is not using Falcon? Or are we > ALWAYS using Falcon now? > > a > > On Tue, Nov 24, 2020 at 10:36 AM Carlos Rovira <carlosrov...@apache.org> > wrote: > > > Hi, > > > > here's a list of Falcon compiler options that could be added to [1]. > > I think an initial copy-paste could be enough for a "first pass", > although > > I guess the older options should come from other sources like the one > from > > Andrew's links or this other one [2]: > > > > [1] > > > > > https://cwiki.apache.org/confluence/display/FLEX/Getting+Started+with+the+Falcon+and+FalconJX+Compilers > > [2] http://renaun.com/blog/2006/08/list-of-mxmlccompc-arguments/ > > > > > > > > El lun, 23 nov 2020 a las 23:23, Andrew Wetmore (<cottag...@gmail.com>) > > escribió: > > > > > There are quite a few options. Maybe the most likely ones should be on > > the > > > page you were editing, and we can add the other to a sub page. > > > > > > a > > > > > > On Mon, Nov 23, 2020 at 6:19 PM Andrew Wetmore <cottag...@gmail.com> > > > wrote: > > > > > > > @Josh Tynjala <joshtynj...@bowlerhat.dev> did you check this page > [1]? > > > If > > > > not, I can scrape from it. > > > > > > > > a > > > > > > > > 1. http://www.docsultant.com/site2/articles/flex_cmd.html > > > > > > > > On Mon, Nov 23, 2020 at 6:14 PM Andrew Wetmore <cottag...@gmail.com> > > > > wrote: > > > > > > > >> I guess I better jump on that before it all melts away. I probably > > have > > > >> some in some crackly downloads from a decade ago, unless I used them > > to > > > >> feed a fire. > > > >> > > > >> Great work, Josh! > > > >> > > > >> a > > > >> > > > >> On Mon, Nov 23, 2020 at 6:07 PM Josh Tynjala < > > joshtynj...@bowlerhat.dev > > > > > > > >> wrote: > > > >> > > > >>> I've added all of the new export-* and prevent-rename-* options, > > > >>> including > > > >>> descriptions. I also added several more options that I saw were > > > missing. > > > >>> > > > >>> Eventually, someone needs to fill in this page with *all* of the > > > missing > > > >>> options. Especially the core options that already existed during > the > > > Flex > > > >>> days. Adobe has pulled down most of its Flex documentation now, and > > I'm > > > >>> not > > > >>> sure that the Apache version of Flex ever had them fully documented > > > >>> either. > > > >>> Soon, there may be no documentation for these options anywhere on > the > > > >>> web, > > > >>> even for someone persistent and knowledgeable enough to look for > > legacy > > > >>> content. > > > >>> > > > >>> Most of the missing options may be found in this compiler class > > > >>> (descriptions of each option are usually in jsdoc comments): > > > >>> > > > >>> > > > > > > https://github.com/apache/royale-compiler/blob/develop/compiler-common/src/main/java/org/apache/royale/compiler/config/Configuration.java > > > >>> > > > >>> There are likely some more JS-specific options that are not > > documented > > > >>> yet > > > >>> in these compiler classes too: > > > >>> > > > >>> > > > > > > https://github.com/apache/royale-compiler/blob/develop/compiler-jx/src/main/java/org/apache/royale/compiler/clients/JSConfiguration.java > > > >>> > > > >>> > > > > > > https://github.com/apache/royale-compiler/blob/develop/compiler-jx/src/main/java/org/apache/royale/compiler/internal/driver/js/goog/JSGoogConfiguration.java > > > >>> > > > >>> -- > > > >>> Josh Tynjala > > > >>> Bowler Hat LLC <https://bowlerhat.dev> > > > >>> > > > >>> > > > >>> On Fri, Nov 20, 2020 at 1:08 PM Josh Tynjala < > > > joshtynj...@bowlerhat.dev> > > > >>> wrote: > > > >>> > > > >>> > I'll try to fill in the details soon. > > > >>> > > > > >>> > -- > > > >>> > Josh Tynjala > > > >>> > Bowler Hat LLC <https://bowlerhat.dev> > > > >>> > > > > >>> > > > > >>> > On Fri, Nov 20, 2020 at 11:42 AM Andrew Wetmore < > > cottag...@gmail.com > > > > > > > >>> > wrote: > > > >>> > > > > >>> >> I have added a section that includes the four compiler options > > that > > > >>> Carlos > > > >>> >> mentioned. If there are more that, when used, reduce output > size, > > > they > > > >>> >> should go there. I have not populated the descriptions, as a > smart > > > >>> person > > > >>> >> should do that. > > > >>> >> > > > >>> >> a > > > >>> >> > > > >>> >> On Fri, Nov 20, 2020 at 3:23 PM Andrew Wetmore < > > cottag...@gmail.com > > > > > > > >>> >> wrote: > > > >>> >> > > > >>> >> > Yes, that page is a good location. Should we start a > subsection > > > for > > > >>> >> these > > > >>> >> > options which have the benefit of reducing output size? > > > >>> >> > > > > >>> >> > a > > > >>> >> > > > > >>> >> > On Fri, Nov 20, 2020 at 1:48 PM Carlos Rovira < > > > >>> carlosrov...@apache.org> > > > >>> >> > wrote: > > > >>> >> > > > > >>> >> >> Hi Josh, > > > >>> >> >> > > > >>> >> >> thanks for working on this. I finally could get here after > > weeks > > > of > > > >>> >> hard > > > >>> >> >> work in other things with almost not time. > > > >>> >> >> I tried in Tour de Jewel with: > > > >>> >> >> > > > >>> >> >> -export-public-symbols=false > > > >>> >> >> -prevent-rename-protected-symbols=false > > > >>> >> >> -prevent-rename-internal-symbols=false > > > >>> >> >> -prevent-rename-public-static-methods=false > > > >>> >> >> -prevent-rename-public-instance-methods=false > > > >>> >> >> > > > >>> >> >> (for what I read that's the set it can be used without > breaking > > > >>> app) > > > >>> >> >> > > > >>> >> >> and a downsize from 1045kb to 910kb so amazing! :) > > > >>> >> >> > > > >>> >> >> I'll try to add to TodoMVC as well and see what happens ;) > > > >>> >> >> > > > >>> >> >> @Andrew I think you and Josh can add this doc to the Royale > > Docs > > > >>> >> compiler > > > >>> >> >> options page here [1] > > > >>> >> >> > > > >>> >> >> [1] > > > https://apache.github.io/royale-docs/compiler/compiler-options > > > >>> >> >> > > > >>> >> >> > > > >>> >> >> > > > >>> >> >> El mar, 10 nov 2020 a las 23:36, Josh Tynjala (< > > > >>> >> joshtynj...@bowlerhat.dev > > > >>> >> >> >) > > > >>> >> >> escribió: > > > >>> >> >> > > > >>> >> >> > Hi Andrew, > > > >>> >> >> > > > > >>> >> >> > Yes, I can help with that! > > > >>> >> >> > > > > >>> >> >> > -- > > > >>> >> >> > Josh Tynjala > > > >>> >> >> > Bowler Hat LLC <https://bowlerhat.dev> > > > >>> >> >> > > > > >>> >> >> > > > > >>> >> >> > On Mon, Nov 9, 2020 at 3:22 PM Andrew Wetmore < > > > >>> cottag...@gmail.com> > > > >>> >> >> wrote: > > > >>> >> >> > > > > >>> >> >> > > Josh, this is very interesting. I would like to include > an > > > >>> >> actionable > > > >>> >> >> > > amount of this information in our user documentation. If > I > > > >>> create a > > > >>> >> >> page > > > >>> >> >> > in > > > >>> >> >> > > the help docs for it, can you help me populate > instructions > > > >>> based > > > >>> >> on > > > >>> >> >> your > > > >>> >> >> > > researchs? > > > >>> >> >> > > > > > >>> >> >> > > Thanks! > > > >>> >> >> > > > > > >>> >> >> > > Andrew > > > >>> >> >> > > > > > >>> >> >> > > On Mon, Nov 9, 2020 at 6:16 PM Josh Tynjala < > > > >>> >> >> joshtynj...@bowlerhat.dev> > > > >>> >> >> > > wrote: > > > >>> >> >> > > > > > >>> >> >> > > > Hi all, > > > >>> >> >> > > > > > > >>> >> >> > > > Some of you have probably been wondering about my > changes > > > to > > > >>> the > > > >>> >> >> > compiler > > > >>> >> >> > > > over the last year or more. I apologize again for > > > >>> occasionally > > > >>> >> >> breaking > > > >>> >> >> > > > things for short periods. It's been quite a challenge > > > getting > > > >>> >> this > > > >>> >> >> > stuff > > > >>> >> >> > > > working, but I'm excited to finally be able to report > > some > > > >>> real > > > >>> >> >> > > > improvements that pretty much anyone should be able to > > take > > > >>> >> >> advantage > > > >>> >> >> > of > > > >>> >> >> > > > when building a Royale app. > > > >>> >> >> > > > > > > >>> >> >> > > > First some background. A while back, Harbs asked me to > > look > > > >>> into > > > >>> >> >> ways > > > >>> >> >> > of > > > >>> >> >> > > > reducing the file size of release builds. As you may > > know, > > > >>> we use > > > >>> >> >> > > Google's > > > >>> >> >> > > > Closure compiler to optimize our generated JavaScript. > > > >>> Closure > > > >>> >> can > > > >>> >> >> be > > > >>> >> >> > > very > > > >>> >> >> > > > aggressive in its optimizations, by renaming symbols > > > (things > > > >>> like > > > >>> >> >> > > variable > > > >>> >> >> > > > and function names) and removing "dead code" that is > > > >>> detected as > > > >>> >> >> never > > > >>> >> >> > > > being called. > > > >>> >> >> > > > > > > >>> >> >> > > > Closure's optimizations are good, but they also require > > > >>> >> developers > > > >>> >> >> to > > > >>> >> >> > be > > > >>> >> >> > > > very careful about how they write their JavaScript > code. > > > >>> When you > > > >>> >> >> > enable > > > >>> >> >> > > > Closure's full optimizations, you are not allowed to > use > > > >>> certain > > > >>> >> >> > > JavaScript > > > >>> >> >> > > > features because Closure cannot analyze them properly. > > For > > > >>> >> instance, > > > >>> >> >> > > > consider the following code: > > > >>> >> >> > > > > > > >>> >> >> > > > var propName= "myProp"; > > > >>> >> >> > > > var value = obj[propName]; > > > >>> >> >> > > > > > > >>> >> >> > > > When you dynamically access a property with a string, > > > Closure > > > >>> >> cannot > > > >>> >> >> > > > reliably know that the property exists and will be > > accessed > > > >>> at > > > >>> >> >> runtime. > > > >>> >> >> > > It > > > >>> >> >> > > > may decide to rename or remove that property, which > would > > > >>> break > > > >>> >> >> things > > > >>> >> >> > at > > > >>> >> >> > > > runtime. > > > >>> >> >> > > > > > > >>> >> >> > > > ActionScript supports many of the same restricted > dynamic > > > >>> >> features > > > >>> >> >> too, > > > >>> >> >> > > so > > > >>> >> >> > > > if you want to support the entire AS3 language, we > can't > > > let > > > >>> >> >> Closure do > > > >>> >> >> > > its > > > >>> >> >> > > > full optimization. Luckily, Closure also provides a bit > > of > > > a > > > >>> >> >> backdoor: > > > >>> >> >> > it > > > >>> >> >> > > > allows you to "export" symbols, which means that they > > won't > > > >>> be > > > >>> >> >> renamed > > > >>> >> >> > > and > > > >>> >> >> > > > they won't be removed as dead code. Traditionally, we > > have > > > >>> made > > > >>> >> >> heavy > > > >>> >> >> > use > > > >>> >> >> > > > of this exporting feature in Royale. > > > >>> >> >> > > > > > > >>> >> >> > > > Harbs wanted to know if we absolutely needed to export > > > >>> everything > > > >>> >> >> that > > > >>> >> >> > we > > > >>> >> >> > > > currently export, and if we could potentially allow > > > >>> developers to > > > >>> >> >> turn > > > >>> >> >> > > off > > > >>> >> >> > > > exporting entirely, as long as they follow the stricter > > > rules > > > >>> >> >> required > > > >>> >> >> > by > > > >>> >> >> > > > Closure. > > > >>> >> >> > > > > > > >>> >> >> > > > I won't go into all of the details, but over the last > > > several > > > >>> >> >> months, > > > >>> >> >> > > I've > > > >>> >> >> > > > been changing the compiler to give developers more > > control > > > >>> over > > > >>> >> >> release > > > >>> >> >> > > > builds. In particular, control over which symbols get > > > >>> exported, > > > >>> >> but > > > >>> >> >> > also > > > >>> >> >> > > > the ability to block Closure from renaming symbols that > > > >>> haven't > > > >>> >> been > > > >>> >> >> > > > exported. > > > >>> >> >> > > > > > > >>> >> >> > > > Now, for some of the results. I'm going to share the > > output > > > >>> file > > > >>> >> >> size > > > >>> >> >> > of > > > >>> >> >> > > > the release build for several Royale projects with > > various > > > >>> >> different > > > >>> >> >> > > > compiler options. > > > >>> >> >> > > > > > > >>> >> >> > > > For the example projects included with Royale, I built > > > >>> >> royale-asjs > > > >>> >> >> > commit > > > >>> >> >> > > > 94f12ed0e564b0b443834400dc2fc06d61b90a8a from October > 26, > > > >>> 2020. > > > >>> >> If > > > >>> >> >> you > > > >>> >> >> > > want > > > >>> >> >> > > > to try building these examples yourself, the file sizes > > of > > > >>> >> release > > > >>> >> >> > builds > > > >>> >> >> > > > may be slightly different, if you use a different > commit. > > > >>> >> >> > > > > > > >>> >> >> > > > SpectrumBrowser is a project developed by Harbs and his > > > >>> team. I > > > >>> >> used > > > >>> >> >> > > commit > > > >>> >> >> > > > d25a3def972b15ec029ae838f1a8a677d2d158bd from October > 20 > > > for > > > >>> the > > > >>> >> >> > results > > > >>> >> >> > > > below. Repo: > > https://github.com/unhurdle/spectrum-royale/ > > > >>> >> >> > > > > > > >>> >> >> > > > To establish a baseline, I built all of these projects > > with > > > >>> the > > > >>> >> >> older > > > >>> >> >> > > > Royale 0.9.7 compiler first. > > > >>> >> >> > > > > > > >>> >> >> > > > ========== > > > >>> >> >> > > > Baseline: royale-compiler 0.9.7 > > > >>> >> >> > > > ========== > > > >>> >> >> > > > > > > >>> >> >> > > > HelloWorld: 68 KB > > > >>> >> >> > > > ASDoc: 231 KB > > > >>> >> >> > > > TourDeJewel: 1074 KB > > > >>> >> >> > > > SpectrumBrowser: 900 KB > > > >>> >> >> > > > > > > >>> >> >> > > > Again, I am building the same AS3/MXML code every time, > > but > > > >>> these > > > >>> >> >> first > > > >>> >> >> > > > numbers are from building with the older compiler. All > > apps > > > >>> build > > > >>> >> >> and > > > >>> >> >> > run > > > >>> >> >> > > > successfully. > > > >>> >> >> > > > > > > >>> >> >> > > > ----- > > > >>> >> >> > > > > > > >>> >> >> > > > The rest of the results are built with royale-compiler > > > commit > > > >>> >> >> > > > df8bd9f686f1bbf89539e545377b2797c646172c from November > 3. > > > >>> >> >> > > > > > > >>> >> >> > > > All results below include the difference in KB and %. > > These > > > >>> >> values > > > >>> >> >> are > > > >>> >> >> > > > always in comparison to the baseline numbers above. > > > >>> >> >> > > > > > > >>> >> >> > > > ========== > > > >>> >> >> > > > Result 1: 0.9.8 default options > > > >>> >> >> > > > ========== > > > >>> >> >> > > > > > > >>> >> >> > > > HelloWorld: 84 KB (+10 KB / +24%) > > > >>> >> >> > > > ASDoc: 254 KB (+23 KB / +10%) > > > >>> >> >> > > > TourDeJewel: 1105 KB (+31 KB / +3%) > > > >>> >> >> > > > SpectrumBrowser: 936 KB (+36 KB / +4%) > > > >>> >> >> > > > > > > >>> >> >> > > > These examples are slightly larger when built with the > > > newer > > > >>> >> >> compiler. > > > >>> >> >> > > > That's expected. It's not ideal, but in the process of > > > >>> testing a > > > >>> >> >> > > multitude > > > >>> >> >> > > > of things to be sure that nothing had broken after my > > > >>> compiler > > > >>> >> >> > changes, I > > > >>> >> >> > > > discovered some cases where exporting a symbol didn't > > > >>> actually > > > >>> >> work > > > >>> >> >> > > > correctly in 0.9.7! To properly fix the bug and export > > > these > > > >>> >> >> symbols, > > > >>> >> >> > > there > > > >>> >> >> > > > was no choice but to make the file size a bit larger. > > > >>> >> >> > > > > > > >>> >> >> > > > ========== > > > >>> >> >> > > > Result 2: Disable export > > > >>> >> >> > > > ========== > > > >>> >> >> > > > > > > >>> >> >> > > > HelloWorld: 74 KB (+6 KB / +9%) > > > >>> >> >> > > > ASDoc: 227 KB (-4 KB / -2%) > > > >>> >> >> > > > TourDeJewel: 942 KB (-132 KB / -12%) > > > >>> >> >> > > > SpectrumBrowser: 882 KB (-18 KB / -2%) > > > >>> >> >> > > > > > > >>> >> >> > > > In this round, I added the > *-export-public-symbols=false* > > > >>> >> compiler > > > >>> >> >> > > option. > > > >>> >> >> > > > You may recall that I said earlier that I also modified > > the > > > >>> >> >> compiler to > > > >>> >> >> > > > allow a symbol not to be exported, but still prevent it > > > from > > > >>> >> being > > > >>> >> >> > > renamed. > > > >>> >> >> > > > With that in mind, -export-public-symbols=false > basically > > > >>> tells > > > >>> >> the > > > >>> >> >> > > > compiler that it still can't rename things, but it is > > > >>> allowed to > > > >>> >> >> remove > > > >>> >> >> > > > what it perceives as dead code. > > > >>> >> >> > > > > > > >>> >> >> > > > HelloWorld is still slightly larger than 0.9.7, but the > > > three > > > >>> >> other > > > >>> >> >> > > > examples are now slightly smaller than 0.9.7. > > > >>> >> >> > > > > > > >>> >> >> > > > Most developers should be able to safely add > > > >>> >> >> > -export-public-symbols=false > > > >>> >> >> > > > to their compiler options when building a Royale app. > The > > > >>> only > > > >>> >> time > > > >>> >> >> > that > > > >>> >> >> > > > you might still want this exporting is if you have > > external > > > >>> >> >> JavaScript > > > >>> >> >> > in > > > >>> >> >> > > > your page that isn't part of your Royale app, but it > > needs > > > to > > > >>> >> call > > > >>> >> >> > > > functions/classes in your Royale app. > > > >>> >> >> > > > > > > >>> >> >> > > > ========== > > > >>> >> >> > > > Result 3: Allow non-public things to be renamed > > > >>> >> >> > > > ========== > > > >>> >> >> > > > > > > >>> >> >> > > > HelloWorld: 72 KB (+4 KB / +6%) > > > >>> >> >> > > > ASDoc: 221 KB (-10 KB / -4%) > > > >>> >> >> > > > TourDeJewel: 918 KB (-156 KB / -15%) > > > >>> >> >> > > > SpectrumBrowser: 861 KB (-39 KB / -4%) > > > >>> >> >> > > > > > > >>> >> >> > > > In this round, I used the following compiler options: > > > >>> >> >> > > > > > > >>> >> >> > > > -export-public-symbols=false > > > >>> >> >> > > > > > > >>> >> >> > > > > > > >>> >> >> > > > > > > >>> >> >> > > > > > >>> >> >> > > > > >>> >> >> > > > >>> >> > > > >>> > > > > > > *-prevent-rename-protected-symbols=false-prevent-rename-internal-symbols=false* > > > >>> >> >> > > > > > > >>> >> >> > > > The two new options allow Closure compiler to rename > > > >>> protected > > > >>> >> and > > > >>> >> >> > > internal > > > >>> >> >> > > > symbols. Once again, HelloWorld is still slightly > larger > > > than > > > >>> >> 0.9.7, > > > >>> >> >> > but > > > >>> >> >> > > > the other three examples have gotten smaller again. > > > >>> >> >> > > > > > > >>> >> >> > > > While -prevent-rename-public-symbols=false exists too, > we > > > >>> cannot > > > >>> >> use > > > >>> >> >> > it. > > > >>> >> >> > > > The examples would not work correctly at runtime. This > > > option > > > >>> >> would > > > >>> >> >> > > > probably work in a pure AS3 app, but our implementation > > of > > > >>> MXML > > > >>> >> in > > > >>> >> >> > Royale > > > >>> >> >> > > > uses dynamic language features that Closure restricts. > > > Unless > > > >>> >> that > > > >>> >> >> is > > > >>> >> >> > > > fixed, we need to avoid renaming certain public > symbols. > > > >>> >> >> > > > > > > >>> >> >> > > > Again, most developers should be able to add > > > >>> >> >> > > > -prevent-rename-protected-symbols=false > > > >>> >> >> > > > and -prevent-rename-internal-symbols=false to their > > Royale > > > >>> app's > > > >>> >> >> > compiler > > > >>> >> >> > > > options. You might need to prevent renaming of > > > >>> protected/internal > > > >>> >> >> > symbols > > > >>> >> >> > > > if you access them dynamically. However, in my > > experience, > > > >>> people > > > >>> >> >> are > > > >>> >> >> > > much > > > >>> >> >> > > > more likely to access public symbols dynamically. > > > >>> >> >> > > > > > > >>> >> >> > > > ----- > > > >>> >> >> > > > > > > >>> >> >> > > > ========== > > > >>> >> >> > > > Result 4: Allow public methods to be renamed > > > >>> >> >> > > > ========== > > > >>> >> >> > > > > > > >>> >> >> > > > HelloWorld: 64 KB (-4 KB / -6%) > > > >>> >> >> > > > ASDoc: 206 KB (-25 KB / -11%) > > > >>> >> >> > > > TourDeJewel: 881 KB (-193 KB / -18%) > > > >>> >> >> > > > SpectrumBrowser: 828 KB (-72 KB / -8%) > > > >>> >> >> > > > > > > >>> >> >> > > > In this round, I used the following compiler options: > > > >>> >> >> > > > > > > >>> >> >> > > > -export-public-symbols=false > > > >>> >> >> > > > -prevent-rename-protected-symbols=false > > > >>> >> >> > > > -prevent-rename-internal-symbols=false > > > >>> >> >> > > > > > > >>> >> >> > > > > > > >>> >> >> > > > > > > >>> >> >> > > > > > >>> >> >> > > > > >>> >> >> > > > >>> >> > > > >>> > > > > > > *-prevent-rename-public-static-methods=false-prevent-rename-public-instance-methods=false > > > >>> >> >> > > > * > > > >>> >> >> > > > > > > >>> >> >> > > > The two new options allow Closure to rename methods > that > > > are > > > >>> >> public. > > > >>> >> >> > Now, > > > >>> >> >> > > > all four examples are smaller than 0.9.7, and the file > > size > > > >>> >> >> difference > > > >>> >> >> > is > > > >>> >> >> > > > getting even more dramatic. > > > >>> >> >> > > > > > > >>> >> >> > > > Once again, -prevent-rename-public-static-methods=false > > and > > > >>> >> >> > > > -prevent-rename-public-instance-methods=false should be > > > safe > > > >>> for > > > >>> >> >> most > > > >>> >> >> > > > developers to enable when compiling their Royale app. > In > > my > > > >>> >> >> experience, > > > >>> >> >> > > > calling methods dynamically is rare. > > > >>> >> >> > > > > > > >>> >> >> > > > ========== > > > >>> >> >> > > > More new compiler options > > > >>> >> >> > > > ========== > > > >>> >> >> > > > > > > >>> >> >> > > > There are some additional new compiler options > available, > > > but > > > >>> >> using > > > >>> >> >> > them > > > >>> >> >> > > is > > > >>> >> >> > > > likely to break most Royale apps. > > > >>> >> >> > > > > > > >>> >> >> > > > -prevent-rename-public-static-variables=false > > > >>> >> >> > > > -prevent-rename-public-instance-variables=false > > > >>> >> >> > > > -prevent-rename-public-static-accessors=false > > > >>> >> >> > > > -prevent-rename-public-instance-accessors=false > > > >>> >> >> > > > > > > >>> >> >> > > > These options control whether Closure allows variables > or > > > >>> >> accessors > > > >>> >> >> > > > (getters and setters) to be renamed. There are also > > > >>> >> similarly-named > > > >>> >> >> > > options > > > >>> >> >> > > > for protected and internal symbols, if you want more > > > control > > > >>> over > > > >>> >> >> those > > > >>> >> >> > > > too, instead of using > > > >>> -prevent-rename-protected-symbols=false and > > > >>> >> >> > > > -prevent-rename-internal-symbols=false. > > > >>> >> >> > > > > > > >>> >> >> > > > Unfortunately, renaming public variables/accessors is > > > >>> usually not > > > >>> >> >> > > possible > > > >>> >> >> > > > without breaking the app at runtime. In some apps, you > > > might > > > >>> be > > > >>> >> >> able to > > > >>> >> >> > > > allow public static members to be renamed. However, in > my > > > >>> >> >> experience, > > > >>> >> >> > > > binding to static constants is pretty common, and > > renaming > > > >>> breaks > > > >>> >> >> those > > > >>> >> >> > > > bindings. > > > >>> >> >> > > > > > > >>> >> >> > > > ========== > > > >>> >> >> > > > Next Steps > > > >>> >> >> > > > ========== > > > >>> >> >> > > > > > > >>> >> >> > > > Ideally, I'd like to make it possible for developers to > > be > > > >>> able > > > >>> >> to > > > >>> >> >> tell > > > >>> >> >> > > > Closure that it's allowed to rename all symbols, > > including > > > >>> public > > > >>> >> >> > ones. I > > > >>> >> >> > > > believe that we could see even more file size savings > in > > > >>> release > > > >>> >> >> builds > > > >>> >> >> > > if > > > >>> >> >> > > > Closure works with full optimizations for all symbols. > > > >>> Obviously, > > > >>> >> >> > > > ActionScript developers would be required to strictly > > > follow > > > >>> >> >> Closure's > > > >>> >> >> > > > rules, if they opt into renaming of public symbols, but > > > >>> that's a > > > >>> >> >> choice > > > >>> >> >> > > > that they should be allowed to make. > > > >>> >> >> > > > > > > >>> >> >> > > > As I mentioned above, our implementation of MXML and > > > binding > > > >>> uses > > > >>> >> >> > dynamic > > > >>> >> >> > > > access, which is not compatible with Closure's full > > > >>> >> optimizations. > > > >>> >> >> To > > > >>> >> >> > > > support those optimizations, I will need to explore > > changes > > > >>> to > > > >>> >> how > > > >>> >> >> we > > > >>> >> >> > > > generate JS for MXML, and how it gets parsed at > runtime. > > > >>> >> >> > > > > > > >>> >> >> > > > We previously discussed this subject a bit in this > older > > > >>> thread > > > >>> >> from > > > >>> >> >> > > > January 2020: > > > >>> >> >> > > > > > > >>> >> >> > > > > > > >>> >> >> > > > > > > >>> >> >> > > > > > >>> >> >> > > > > >>> >> >> > > > >>> >> > > > >>> > > > > > > https://lists.apache.org/thread.html/r843e55252e37967b71b1430a2a904719791d698f3e5e2a79de74e493%40%3Cdev.royale.apache.org%3E > > > >>> >> >> > > > > > > >>> >> >> > > > At the time, I tried out some ideas that we came up > with > > > >>> while > > > >>> >> >> > > > brainstorming, but all had various downsides that > didn't > > > make > > > >>> >> for an > > > >>> >> >> > > > obvious winner. In the end, I decided to set further > > > >>> >> investigation > > > >>> >> >> > aside > > > >>> >> >> > > > and first focus on exporting/renaming stuff. Now, I'm > > ready > > > >>> to > > > >>> >> take > > > >>> >> >> a > > > >>> >> >> > > > second look with a fresh perspective, and maybe we'll > > have > > > >>> some > > > >>> >> new > > > >>> >> >> > ideas > > > >>> >> >> > > > to try. > > > >>> >> >> > > > > > > >>> >> >> > > > ----- > > > >>> >> >> > > > > > > >>> >> >> > > > That was really long, so thank you for reading, if you > > made > > > >>> it to > > > >>> >> >> the > > > >>> >> >> > > end! > > > >>> >> >> > > > > > > >>> >> >> > > > TL;DR: By enabling certain, new compiler options, most > > > Royale > > > >>> >> >> > developers > > > >>> >> >> > > > can make their app release builds smaller. > Additionally, > > I > > > >>> plan > > > >>> >> to > > > >>> >> >> keep > > > >>> >> >> > > > investigating, and I expect to find more ways to reduce > > > file > > > >>> >> size in > > > >>> >> >> > the > > > >>> >> >> > > > future. > > > >>> >> >> > > > > > > >>> >> >> > > > -- > > > >>> >> >> > > > Josh Tynjala > > > >>> >> >> > > > Bowler Hat LLC <https://bowlerhat.dev> > > > >>> >> >> > > > > > > >>> >> >> > > > > > >>> >> >> > > > > > >>> >> >> > > -- > > > >>> >> >> > > Andrew Wetmore > > > >>> >> >> > > > > > >>> >> >> > > http://cottage14.blogspot.com/ > > > >>> >> >> > > > > > >>> >> >> > > > > >>> >> >> > > > >>> >> >> > > > >>> >> >> -- > > > >>> >> >> Carlos Rovira > > > >>> >> >> Apache Member & Apache Royale PMC > > > >>> >> >> *Apache Software Foundation* > > > >>> >> >> http://about.me/carlosrovira > > > >>> >> >> > > > >>> >> > > > > >>> >> > > > > >>> >> > -- > > > >>> >> > Andrew Wetmore > > > >>> >> > > > > >>> >> > http://cottage14.blogspot.com/ > > > >>> >> > > > > >>> >> > > > > >>> >> > > > > >>> >> > > > > >>> >> > > > > >>> >> > > > >>> >> -- > > > >>> >> Andrew Wetmore > > > >>> >> > > > >>> >> http://cottage14.blogspot.com/ > > > >>> >> > > > >>> > > > > >>> > > > >> > > > >> > > > >> -- > > > >> Andrew Wetmore > > > >> > > > >> http://cottage14.blogspot.com/ > > > >> > > > >> > > > >> > > > >> > > > >> > > > > > > > > -- > > > > Andrew Wetmore > > > > > > > > http://cottage14.blogspot.com/ > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Andrew Wetmore > > > > > > http://cottage14.blogspot.com/ > > > > > > > > > -- > > Carlos Rovira > > Apache Member & Apache Royale PMC > > *Apache Software Foundation* > > http://about.me/carlosrovira > > > > > -- > Andrew Wetmore > > http://cottage14.blogspot.com/ >
