js-dynamic-access-unknown-members is false by default: https://github.com/apache/royale-compiler/blob/3ceee572c331770f3852a7b77c5e5c5c2f414909/compiler-jx/src/main/java/org/apache/royale/compiler/clients/JSConfiguration.java#L177
With js-dynamic-access-unknown-members, the "dynamic-access" part of the name refers to how the JS is generated. It basically says that if you try to access a member that doesn't exist on a class, the generated JS should use brackets/string (obj["field"]) instead of a dot (obj.field) for member access. The idea is to force Closure compiler not to rename the name of the field on that particular line because Closure leaves strings as-is. setTheme() is not declared on the Object class, so the generated JS output for obj.setTheme() will be obj["setTheme"]() if js-dynamic-access-unknown-members is true. If js-dynamic-access-unknown-members is false, then it will remain as obj.setTheme() in the generated JS, which may or may not be renamed by Closure in the release build (in some cases, Closure decides not to rename things, for whatever magical reasons it has... yes, even after months of wrangling Closure, I still don't completely understand everything that it does). -- Josh Tynjala Bowler Hat LLC <https://bowlerhat.dev> On Wed, Nov 10, 2021 at 11:59 PM Yishay Weiss <yishayj...@hotmail.com> wrote: > Then I guess -js-dynamic-access-unknown-members=true by default (it’s not > documented to be)? > > I’m still confused about the terminology. In my example I have > > obj.setTheme(“foo.css”) where obj is an AS3 Object. Is that what’s called > loosely typed code, which implies that -js-dynamic-access-unknown-members > needs to be true? > > I’m also not sure why the term dynamic-access applies here. My code is > doing obj.setTheme(), not obj[“setTheme”](). > > From: Josh Tynjala<mailto:joshtynj...@bowlerhat.dev> > Sent: Wednesday, November 10, 2021 7:20 PM > To: dev@royale.apache.org<mailto:dev@royale.apache.org> > Subject: Re: Why Does GCC Not Rename This? > > Yes, that seems correct. The prevent-rename options only apply to strictly > typed code. For loosely typed code, it's js-dynamic-access-unknown-members. > > -- > Josh Tynjala > Bowler Hat LLC <https://bowlerhat.dev> > > > On Wed, Nov 10, 2021 at 12:14 AM Harbs <harbs.li...@gmail.com> wrote: > > > Josh, just to make sure I understand what the options do: > > > > If -prevent-rename-public-symbols=false and > > -js-dynamic-access-unknown-members=false, then external js methods (i.e. > > setTheme) will be renamed. > > > > If -prevent-rename-public-symbols=false and > > -js-dynamic-access-unknown-members=true, then external js methods (i.e. > > setTheme) will not be renamed, but typed public methods will be renamed. > > > > Did I get that right? > > > > > On Nov 9, 2021, at 7:21 PM, Josh Tynjala <joshtynj...@bowlerhat.dev> > > wrote: > > > > > > Unlike previously, these days, looser code is much more likely to work > > with > > > the default compiler options. That was a nice side effect of my efforts > > to > > > do the opposite. Harbs wanted me to get the compiler to rename/minify > > even > > > more than it was able to before, which I achieved after many months of > > > work. In the process, I fixed a ton of issues that helped get loose > > typing > > > working better. > > > > > > As you all probably recall, I added a bunch of compiler options to > > control > > > the compiler's behavior in regards to exporting and renaming in release > > > builds compiled with Closure compiler. These new compiler options allow > > > people to go back to the old behavior, where you were required to > almost > > > always use strict types, and they allow more things to be > > renamed/minified > > > than we ever allowed previously (assuming that you write your code > > > carefully enough). Details in my old threads with the title "Compiler > > > options for reducing release build size of Royale projects" (and "Part > > 2"). > > > > > > -- > > > Josh Tynjala > > > Bowler Hat LLC <https://bowlerhat.dev> > > > > > > > > > On Tue, Nov 9, 2021 at 4:15 AM Yishay Weiss <yishayj...@hotmail.com> > > wrote: > > > > > >> I was playing around with it, trying to demonstrate the advantages of > > >> typed objects, expecting Object to mess up function calls. The demo > > glitch > > >> was that GCC was fine with a looser version. > > >> > > >> From: Harbs<mailto:harbs.li...@gmail.com> > > >> Sent: Tuesday, November 9, 2021 2:13 PM > > >> To: dev@royale.apache.org<mailto:dev@royale.apache.org> > > >> Subject: Re: Why Does GCC Not Rename This? > > >> > > >> Why is it Object and not “Editor”? > > >> > > >> private var editor:Editor; > > >> > > >> > > >>> On Nov 9, 2021, at 2:03 PM, Harbs <harbs.li...@gmail.com> wrote: > > >>> > > >>> Oh. I misread what you wrote. I thought you were asking about > “theme”. > > >>> > > >>> -js-dynamic-access-unknown-members=true is probably effecting that. > > What > > >> compiler option is being used? > > >>> > > >>>> On Nov 9, 2021, at 1:59 PM, Harbs <harbs.li...@gmail.com> wrote: > > >>>> > > >>>> @nocollapse is what prevents renaming. > > >>>> > > >>>> Why it’s writing @nocollapse is another question... > > >>>> > > >>>>> On Nov 9, 2021, at 1:36 PM, Yishay Weiss <yishayj...@hotmail.com> > > >> wrote: > > >>>>> > > >>>>> > > >>>>> An application that uses this class [1] minifies to this [2]. In > > >>>>> > > >>>>> org.apache.royale.ace.ACEEditor.prototype.set__theme = > > function(value) > > >> { > > >>>>> this.org_apache_royale_ace_ACEEditor__theme = value; > > >>>>> var /** @type {Object} */ obj = this.editor; > > >>>>> obj.setTheme(value); > > >>>>> }; > > >>>>> > > >>>>> I expected the closure compiler to rename setTheme(), but instead > it > > >> retained it. How did it know to do that? Is it because it’s an Object > > type? > > >>>>> > > >>>>> > > >>>>> [1] Apache Paste Bucket<https://paste.apache.org/gg0dy> > > >>>>> [2] Apache Paste Bucket<https://paste.apache.org/4c5f0> > > >>>> > > >>> > > >> > > >> > > > > > >
