I agree 100% Harbs. And I think that is not difficult to achieve. The decisions and collaborative effort need to take place in the planning side of things to figure out the reasonable set of granular things to support. Perhaps we can do that once the 'dust has settled' after 0.9.6 is out. Then your 3 sets (or whatever is decided to be the menu) could simply be defined as a collection of settings for those, with people free to tune things at a more granular level if they wanted. I might want to, for example, be able to strip out reflection data from UI based Framework classes but keep it for all other framework stuff, and all my own custom UI components, (perhaps that sounds weird, but I can think of this as being useful in a real-world scenario with Crux). Whether that level or control is reasonable for us to support is probably questionable. But I think it is *possible*. This is the same type of granular switching I was trying to explain for switching off Vector runtime checking in recent months, but I did not get a sense that anyone clearly understood what I was trying to convey at the time (my impression only).
I think the main thing we are missing (from my perspective) is to avoid the need to recompile the swcs to swap things in and out. Anyway, I will stop talking about this, I just wanted to highlight the fact that I believe we can technically meet most people's needs, whatever they are, but that I also think the general need is best served by matching as3 behavior by default, as Josh has proposed for public vars. On Tue, Sep 17, 2019 at 10:28 PM Harbs <[email protected]> wrote: > Rather than having to specify a whole slew of compiler options, I’d like > to see 2 or 3 compiler configurations that would set the defaults on a > group of options to get the best default behavior for a use case. > Maybe something like this: > > js-config=compatible (for maximum, compatibility with Flash behavior) > js-config=optimized (for minimum code size) > js-config=safe (for best type safety but not necessarily Flash compatible) > > Obviously, you could override the defaults on any one of these, but I hope > we could give predefined sets of defaults which cover the vast majority of > use cases out of the box. > > It’s hard learning all the compiler options, but being able to specify a > few sets of defaults seems reasonable. > > Harbs > > > On Sep 17, 2019, at 11:02 AM, Greg Dove <[email protected]> wrote: > > > > I personally would use a non-default setting to keep things as they are > > right now, but I agree with Josh in that as it is, I don't think it's a > > good hurdle to present to new users, or people in general that simply > want > > things to 'work' out of the box, based on what they should reasonably > > expect to work. The language layer is the foundation for building > > everything else. People have serious doubts when things don't work right > at > > that level. I have had to reassure people about this recently (XML - > still > > working on it - soon!). > > > > We have only touched the surface of what we could do with GCC for tuning > > the output. There are ways to have all the default stuff in there but > > selectively remove it from release builds without having to recompile > > library code, for example. So I think it is possible that we could > provide > > flexible solutions that match whatever we consider people want. > > But in terms of defaults, is it not obvious that it we should be guided > by > > actionscript 3 language itself and the reference implementation we > already > > have? We can't always match things, but I think the onus is on us to get > as > > close as we can by default. > > > > > > On Tue, Sep 17, 2019 at 5:59 PM Alex Harui <[email protected]> > wrote: > > > >> Some folks want us to get smarter and not automatically export all > public > >> methods and getter/setters. There are a lot of just-in-case strings in > >> Royale apps. That's not good. So better control over things even after > >> compiling without being painful to use is the goal. > >> > >> My 2 cents, > >> -Alex > >> > >> On 9/16/19, 12:39 PM, "Josh Tynjala" <[email protected]> > wrote: > >> > >> I was thinking about this some more, and is there anything else > that's > >> public that also we allow to be renamed? I'm not aware of anything, > but > >> maybe I've missed something. If it's true, it seems inconsistent to > >> allow > >> public variables to be the one exception that should be renamed. If > >> public > >> methods, properties, and other things can't be renamed, public > >> variables > >> shouldn't be either. > >> > >> Looking into the configuration classes, I see that we have the > >> export-public-symbols compiler option. That seems like it's the one > >> that is > >> meant to control whether public things should be renamed or not. It's > >> true > >> by default. I have no issue with public variables being renamed when > >> it's > >> false. Again, that would be consistent with how the compiler handles > >> other > >> public things. > >> > >> -- > >> Josh Tynjala > >> Bowler Hat LLC < > >> > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C384429ef197b497fff9408d73add9c25%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637042595795496907&sdata=ii0taRMhu0bD0Ea577FNZ9CzDn%2B60MAdu7VsVIA92W4%3D&reserved=0 > >>> > >> > >> > >> On Mon, Sep 16, 2019 at 11:13 AM Josh Tynjala < > >> [email protected]> > >> wrote: > >> > >>> Unfortunately, people actively avoid using public vars because we > >> warn > >>> about them. Our warnings are too aggressive if it doesn't actually > >> matter > >>> most of the time. Plus, this warning leaves a bad impression because > >> it's > >>> such a basic feature of the language that pretty much everyone uses. > >>> > >>> What can we do to provide a more sensible default behavior, while > >> also > >>> giving someone the ability to tell the compiler that everything can > >> be > >>> renamed (or selective renaming)? > >>> > >>> We could add an option that doesn't rename public things by default, > >> but > >>> can also be toggled to rename everything. I guess we could have some > >>> @royalewhatever annotations to give someone selective control over > >> which > >>> things are renamed or not, if someone needs that. Thoughts? > >>> > >>> -- > >>> Josh Tynjala > >>> Bowler Hat LLC < > >> > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C384429ef197b497fff9408d73add9c25%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637042595795496907&sdata=ii0taRMhu0bD0Ea577FNZ9CzDn%2B60MAdu7VsVIA92W4%3D&reserved=0 > >>> > >>> > >>> > >>> On Mon, Sep 16, 2019 at 10:50 AM Alex Harui <[email protected] > >>> > >>> wrote: > >>> > >>>> I'm not sure I understand your proposal. Are you proposing that all > >>>> public variables will be quoted and thus not renamed so we never > >> warn > >>>> again? I am not in favor of that. IMO, the vast majority of > >> public vars > >>>> can be renamed without penalty. It is only certain classes that > >> will be > >>>> mapped to external code that matter. > >>>> > >>>> My 2 cents, > >>>> -Alex > >>>> > >>>> On 9/16/19, 10:46 AM, "Josh Tynjala" <[email protected]> > >> wrote: > >>>> > >>>> You're right. After a number of tests, I cannot find any > >> annotation > >>>> (or > >>>> combination of them) that will prevent the renaming of variables > >>>> defined on > >>>> a prototype. All of the official advice that I see from Google > >>>> suggests > >>>> quoting the properties (or using externs). So, from a Royale > >>>> perspective, > >>>> it looks like quoting the public variable's name is our best > >> option. > >>>> > >>>> Similar to how we handle js-dynamic-access-unknown-members, we > >> can > >>>> quote > >>>> the public variable's name when getting or setting it in JS: > >>>> > >>>> var foo = new Foo(); > >>>> foo["bar"] = 2; > >>>> var baz = foo["bar"]; > >>>> > >>>> In this case, we also need to quote the public variable's name > >> when > >>>> declaring it on the prototype: > >>>> > >>>> Foo.prototype["bar"] = 3; > >>>> > >>>> I did some tests, and I can confirm that Closure will preserve > >> the > >>>> public > >>>> variable's name, similar to how it preserves the names when we > >> declare > >>>> public getters and setters. I'm going to make this change and > >> turn off > >>>> warn-public-vars. > >>>> > >>>> (To be clear, I'm only going to change how the emitter handles > >> public > >>>> variables specifically. Behavior for other types of property > >> access > >>>> will > >>>> remain the same.) > >>>> > >>>> -- > >>>> Josh Tynjala > >>>> Bowler Hat LLC < > >>>> > >> > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C384429ef197b497fff9408d73add9c25%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637042595795506897&sdata=5rzE%2B70a1xN0uhkP0oCfoXZpH1EFtRk4HXWQXbVF7%2Fc%3D&reserved=0 > >>>>> > >>>> > >>>> > >>>> On Mon, Sep 16, 2019 at 10:06 AM Alex Harui > >> <[email protected] > >>>>> > >>>> wrote: > >>>> > >>>>> Feel free to revisit. IIRC, the issue is that you can't > >> @export a > >>>> "var". > >>>>> You can only @export a function because @export sets up a > >> reference > >>>> to the > >>>>> renamed function and you can't set up a reference to simple > >> vars. > >>>>> > >>>>> Class Josh { > >>>>> Static var foo:int = 1; > >>>>> } > >>>>> > >>>>> Compiles to: > >>>>> > >>>>> Josh.foo = 1; > >>>>> > >>>>> Gets renamed to: > >>>>> > >>>>> a.b = 1; > >>>>> > >>>>> The @export will result in: > >>>>> > >>>>> ['Josh']['foo'] = a.b; > >>>>> > >>>>> And then code that does: > >>>>> > >>>>> Josh.foo = 2; > >>>>> > >>>>> Will not change > >>>>> > >>>>> Console.log(a.b); // 1 (not 2) > >>>>> > >>>>> Of course, I could be wrong.. > >>>>> > >>>>> -Alex > >>>>> > >>>>> On 9/16/19, 9:57 AM, "Josh Tynjala" < > >> [email protected]> > >>>> wrote: > >>>>> > >>>>> I guess I was assuming that @nocollapse combined with > >> @export > >>>> would > >>>>> make it > >>>>> also prevent renaming. I suppose I can test it and see > >> what > >>>> happens. > >>>>> > >>>>> -- > >>>>> Josh Tynjala > >>>>> Bowler Hat LLC < > >>>>> > >>>> > >> > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C384429ef197b497fff9408d73add9c25%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637042595795506897&sdata=5rzE%2B70a1xN0uhkP0oCfoXZpH1EFtRk4HXWQXbVF7%2Fc%3D&reserved=0 > >>>>>> > >>>>> > >>>>> > >>>>> On Mon, Sep 16, 2019 at 9:54 AM Alex Harui > >>>> <[email protected]> > >>>>> wrote: > >>>>> > >>>>>> IMO, the -warn-public-vars is more about the "renaming" > >>>> mentioned in > >>>>> that > >>>>>> link than the "collapse". > >>>>>> > >>>>>> If you have: > >>>>>> > >>>>>> Package { > >>>>>> Class Josh { > >>>>>> Public var name:String; > >>>>>> } > >>>>>> Var foo:Josh = new Josh(); > >>>>>> foo.name = 'josh'; > >>>>>> > >>>>>> I don't think @nocollapse will prevent renaming the > >> 'name' > >>>> property > >>>>> to > >>>>>> something random like 'jt': > >>>>>> > >>>>>> Var foo = new Josh(); > >>>>>> foo.jt = 'josh'; > >>>>>> > >>>>>> AIUI, @nocollapse is used for things that are not > >> obviously > >>>>> mutable. If > >>>>>> you look in the globals in the browser debugger for any > >>>> js-debug > >>>>> version of > >>>>>> a Royale app, you can see the structure: > >>>>>> > >>>>>> org.apache.royale.core > >>>>>> > >>>>>> It was created by code similar to: > >>>>>> > >>>>>> window.org = {}; > >>>>>> window.org.apache = {}; > >>>>>> window.org.apache.royale = {}; > >>>>>> window.org.apache.royale.core = {}; > >>>>>> > >>>>>> Then some class gets added: > >>>>>> > >>>>>> window.org.apache.royale.core.UIBase = function ()... > >>>>>> > >>>>>> And some static might get added to that: > >>>>>> > >>>>>> window.org.apache.royale.core.UIBase.FOO = "BAR"; > >>>>>> > >>>>>> Closure will collapse org.apache.royale.core to just > >>>> something like > >>>>> "bb" > >>>>>> in the js-release output. And that means that code > >> that sets > >>>>> UIBase.FOO > >>>>>> will break because there won't be an > >> org.apache.royale.core > >>>>> structure. > >>>>>> AIUI, nocollapse would prevent collapsing that > >> structure, but > >>>> won't > >>>>> prevent > >>>>>> UIBase and FOO from being renamed. And the renaming > >> mainly > >>>> causes > >>>>> problems > >>>>>> when deserializing data structures coming from a server > >> or > >>>> other > >>>>> external > >>>>>> source. > >>>>>> > >>>>>> Of course, I could be wrong... > >>>>>> -Alex > >>>>>> > >>>>>> On 9/16/19, 9:07 AM, "Josh Tynjala" < > >>>> [email protected]> > >>>>> wrote: > >>>>>> > >>>>>> I was looking through the Closure compiler > >> annotations, > >>>> and I > >>>>> noticed > >>>>>> @nocollapse: > >>>>>> > >>>>>> Denotes a property that should not be collapsed by > >> the > >>>> compiler > >>>>> into a > >>>>>>> variable. The primary use for @nocollapse is to > >> allow > >>>>> exporting of > >>>>>> mutable > >>>>>>> properties. > >>>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>> > >>>> > >> > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FAnnotating-JavaScript-for-the-Closure-Compiler%23nocollapse&data=02%7C01%7Caharui%40adobe.com%7C384429ef197b497fff9408d73add9c25%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637042595795506897&sdata=4B7uvxv0cXrTcKIvIzcdUCdML%2FIKa8iPY20gCbR273U%3D&reserved=0 > >>>>>> > >>>>>> Isn't this collapsing behavior the reason why we > >> needed > >>>> to add > >>>>>> -warn-public-vars? > >>>>>> > >>>>>> -- > >>>>>> Josh Tynjala > >>>>>> Bowler Hat LLC < > >>>>>> > >>>>> > >>>> > >> > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C384429ef197b497fff9408d73add9c25%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637042595795506897&sdata=5rzE%2B70a1xN0uhkP0oCfoXZpH1EFtRk4HXWQXbVF7%2Fc%3D&reserved=0 > >>>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>>> > >>>> > >> > >> > >> > >
