Re: Could @nocollapse be a solution to the -warn-public-vars issue?

Couple of responses inline. On 9/18/19, 12:50 PM, "Greg Dove" wrote: I can see people definitely wanting to exclude it if they never use it in their app, Originally, the REFLECTION_DATA was removed if you didn't use any Reflection classes in the app. I hope that's still true. Although

Re: Could @nocollapse be a solution to the -warn-public-vars issue?

Responses also inline. Beyond this reply, I'm going to dip out and let others contribute their ideas for a bit... because I really need to focus on other things for now. If I go silent that is why. On Thu, Sep 19, 2019 at 7:14 AM Alex Harui wrote: > Responses inline. > > On 9/18/19, 11:53 AM, "

Re: Could @nocollapse be a solution to the -warn-public-vars issue?

Responses inline. On 9/18/19, 11:53 AM, "Greg Dove" wrote: Alex, the idea was to make the js output itself support the options, without any need to manipulate any files at all. Why would you not want to use goog defines? https://nam04.safelinks.protection.outlook.com/?url=https

Re: Could @nocollapse be a solution to the -warn-public-vars issue?

Alex, the idea was to make the js output itself support the options, without any need to manipulate any files at all. Why would you not want to use goog defines? https://github.com/google/closure-compiler/wiki/Annotating-JavaScript-for-the-Closure-Compiler#define-type-description It seems like the

Re: Could @nocollapse be a solution to the -warn-public-vars issue?

I probably won't object to folks trying out different config options, but the 3 buckets Harbs proposed didn't make any sense to me. I would want to turn them all on, and not be sure what the trade-offs are. IMO, modifying the JS from SWCs after compilation is "easy" in the sense that it is all

Re: Could @nocollapse be a solution to the -warn-public-vars issue?

I think it could be as simple as having something like a class (eg. JSBuild) with a bunch of static goog @defines. These could be used to delimit sections of output that provide things like reflection, default initialized, vector runtime checking etc. In a sense it is not much different to how you

Re: Could @nocollapse be a solution to the -warn-public-vars issue?

Absolutely. Now we just need to figure out how… ;-) > On Sep 18, 2019, at 5:10 PM, Josh Tynjala wrote: > >> 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. > > I think that being able to switch things off and on

Re: Could @nocollapse be a solution to the -warn-public-vars issue?

> 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. I think that being able to switch things off and on without recompiling SWCs would be awesome. Without that control, we will continue to struggle with differing opini

Re: Could @nocollapse be a solution to the -warn-public-vars issue?

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 you

Re: Could @nocollapse be a solution to the -warn-public-vars issue?

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

Re: Could @nocollapse be a solution to the -warn-public-vars issue?

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

Re: Could @nocollapse be a solution to the -warn-public-vars issue?

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

Re: Could @nocollapse be a solution to the -warn-public-vars issue?

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

Re: Could @nocollapse be a solution to the -warn-public-vars issue?

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 w

Re: Could @nocollapse be a solution to the -warn-public-vars issue?

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

Re: Could @nocollapse be a solution to the -warn-public-vars issue?

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 lo

Re: Could @nocollapse be a solution to the -warn-public-vars issue?

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 re

Re: Could @nocollapse be a solution to the -warn-public-vars issue?

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 On Mon, Sep 16, 2019 at 9:54 AM Alex Harui wrote: > IMO, the -warn-public-vars is more about t

Re: Could @nocollapse be a solution to the -warn-public-vars issue?

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 ran

Could @nocollapse be a solution to the -warn-public-vars issue?

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://github.com/google/closure-compiler/wiki/An