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

[Greg Dove]

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, "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%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FAnnotating-JavaScript-for-the-Closure-Compiler%23define-type-descriptiondata=02%7C01%7Caharui%40adobe.com%7C05e47962202a40946eac08d73c697d85%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637044296118065315sdata=6RqR1nhJBOv9u0nAwGst325wXtHwWuKozGPZncE2FY0%3Dreserved=0
>
> It seems like the easiest way and it leverages the strength of GCC.
>
> if (JSBuild.includeReflection) {
> regular reflection data
> }
>
> I haven’t spent a lot of time thinking about this, but I don't see how a
> flag like JSBUild.includeReflection will drop reflection data for framework
> classes unless we specify only certain classes as "framework classes" and
> thus give only them that flag.
>

A single flag wouldn't. But with some careful planning a set of bit flags
could be used to achieve reasonable selectability I think. Not something
for most users, I agree. TBH I don't think most people will care about this
level of detail for reflection, but I can see people definitely wanting to
exclude it if they never use it in their app, and I'm sure some might want
to really tune it at a granular level. Perhaps there is simply and on and
off switch and the codeflow approach you mentioned can be introduced later
for people who want the real stuff.

>
> redefining that JSBuild.includeReflection goog define to be false at
> the
> application build stage (which is for illustrative purposes here
> only,  and
> would be true by default), eliminates it from all classes (that have
> had it
> included in the js output) in the release build, just like how
> goog.DEBUG
> works now.
>
> Having alternate swcs sounds complicated to me. It's different, but in
> some
> ways conceptually similar to monkey patching I guess (which works
> also).
> But it seems less desirable than being able to get everything you need
> from
> the one swc.
>
> OT: For the public vars stuff, that is not an issue for AMF
> serialization.
> Reflection classes do support the public var renaming and AMF works
> fine
> with the minimized names. I think the general issue with public vars is
> that people can use regular dynamic access in actionscript, and that
> should
> work by default rather than be another hurdle. But of course it should
> also
> be able to be switched back to how it is now.
>
> public vars is not OT.  It is the subject of this thread.  I'm curious as
> to how AMF supports the minified names.  When an object comes in from the
> server with a "name" property, how do you know it is now called "aa"?
>
> Good call.
The Variabledefinition and AccessorDefinition classes both have getValue
and setValue on-demand getter/setter creation. Support for public vars uses
a single function that serves as a getter/setter internally which supports
the renamed value in terms of getting/setting. Because all this is created
on demand it does not add any overhead at startup, but it works like it
should when it is needed via reflection. It's battle tested, works for AMF
and Crux and I also use it in the manual-tests unit testing setup to run
the same tests across debug and release builds. So to answer your
question... it doesn't know or care what the renamed name is, the
reflection class will map to it via its own gettter/setter approach.


> The ideas for the  granular stuff are interesting, but I think we need
> to
> go with things that are achievable in the near future, unless you
> realistically think the code-flow stuff is something you can work on.
> I don't think it's for me, but I believe I can do the stuff I already
> mentioned. And I don't expect the approaches would be mutually
> exclusive in
> terms of evolving things in the future.
>
> My point is to be careful as to how much time we make folks spend trying
> to understand our compiler options when we might want to do more
> intelligent things instead.  Having metadata or an interface drive the
> output of public var is not complex like code-flow analysis and might avoid
> folks having to learn some of these options or implement more options.  Or
> we might try inspecting GCC's string table to know what strings are being
> used and prevent renaming based on that table.  Code-flow is hard, but GCC
> is using it and we might be able to leverage theirs.
>
> We already have all these compiler options, and I agree they 

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

[Alex Harui]

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%3A%2F%2Fgithub.com%2Fgoogle%2Fclosure-compiler%2Fwiki%2FAnnotating-JavaScript-for-the-Closure-Compiler%23define-type-descriptiondata=02%7C01%7Caharui%40adobe.com%7C05e47962202a40946eac08d73c697d85%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637044296118065315sdata=6RqR1nhJBOv9u0nAwGst325wXtHwWuKozGPZncE2FY0%3Dreserved=0

It seems like the easiest way and it leverages the strength of GCC.

if (JSBuild.includeReflection) {
regular reflection data
}

I haven’t spent a lot of time thinking about this, but I don't see how a flag 
like JSBUild.includeReflection will drop reflection data for framework classes 
unless we specify only certain classes as "framework classes" and thus give 
only them that flag.

redefining that JSBuild.includeReflection goog define to be false at the
application build stage (which is for illustrative purposes here only,  and
would be true by default), eliminates it from all classes (that have had it
included in the js output) in the release build, just like how goog.DEBUG
works now.

Having alternate swcs sounds complicated to me. It's different, but in some
ways conceptually similar to monkey patching I guess (which works also).
But it seems less desirable than being able to get everything you need from
the one swc.

OT: For the public vars stuff, that is not an issue for AMF serialization.
Reflection classes do support the public var renaming and AMF works fine
with the minimized names. I think the general issue with public vars is
that people can use regular dynamic access in actionscript, and that should
work by default rather than be another hurdle. But of course it should also
be able to be switched back to how it is now.

public vars is not OT.  It is the subject of this thread.  I'm curious as to 
how AMF supports the minified names.  When an object comes in from the server 
with a "name" property, how do you know it is now called "aa"?

The ideas for the  granular stuff are interesting, but I think we need to
go with things that are achievable in the near future, unless you
realistically think the code-flow stuff is something you can work on.
I don't think it's for me, but I believe I can do the stuff I already
mentioned. And I don't expect the approaches would be mutually exclusive in
terms of evolving things in the future.

My point is to be careful as to how much time we make folks spend trying to 
understand our compiler options when we might want to do more intelligent 
things instead.  Having metadata or an interface drive the output of public var 
is not complex like code-flow analysis and might avoid folks having to learn 
some of these options or implement more options.  Or we might try inspecting 
GCC's string table to know what strings are being used and prevent renaming 
based on that table.  Code-flow is hard, but GCC is using it and we might be 
able to leverage theirs.

My 2 cents,
-Alex 

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

[Greg Dove]

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 easiest way and it leverages the strength of GCC.

if (JSBuild.includeReflection) {
regular reflection data
}

redefining that JSBuild.includeReflection goog define to be false at the
application build stage (which is for illustrative purposes here only,  and
would be true by default), eliminates it from all classes (that have had it
included in the js output) in the release build, just like how goog.DEBUG
works now.

Having alternate swcs sounds complicated to me. It's different, but in some
ways conceptually similar to monkey patching I guess (which works also).
But it seems less desirable than being able to get everything you need from
the one swc.

OT: For the public vars stuff, that is not an issue for AMF serialization.
Reflection classes do support the public var renaming and AMF works fine
with the minimized names. I think the general issue with public vars is
that people can use regular dynamic access in actionscript, and that should
work by default rather than be another hurdle. But of course it should also
be able to be switched back to how it is now.

The ideas for the  granular stuff are interesting, but I think we need to
go with things that are achievable in the near future, unless you
realistically think the code-flow stuff is something you can work on.
I don't think it's for me, but I believe I can do the stuff I already
mentioned. And I don't expect the approaches would be mutually exclusive in
terms of evolving things in the future.

Whatever the menu 'buckets' are can be debated, but they would simply be
sets of granular settings that people don't have to try to understand if
they don't want to.



On Thu, Sep 19, 2019 at 5:24 AM Alex Harui  wrote:

> 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 regular expressions in text and JS allows for it (at least
> so far).  The compiler already has options to skip linking certain
> classes.  That syntax can be extended to skip or modify some of the JS for
> a class.  Also, the GoogDepsWriter reads just about every file already so
> doing more automated text manipulation is also "easy".
>
> Also note that code-flow-analysis is also possible and may allow us to
> automatically/intelligently modify/remove code someday, so some of these
> options may be interim solutions.  For example, it might be possible to
> know which classes are being passed into Reflection and thus toss the
> reflection data from all of the other classes.
>
> I haven't tried this, but I've also considered that instead of compile
> options that you can link in alternate SWCs with alternate code, or that
> will overwrite the prototype at runtime to alter how things behave.
>
> Also, regarding public vars specifically, it may be that we use metadata
> to generate different code for vars.  We already do that with [Bindable].
>  It may be that if a class isn't a UI class and has [ClassAlias] or
> implements IExternalizable that we convert all vars to getter/setter (or do
> something else to prevent renaming) and that will the right default.  Or
> invent some new metadata to signal different var output.
>
> In summary, large bucket options can be confusing, granular options can be
> painful, but we might be able to use code-flow or other hints and get it
> right more often than we do now.
>
> My 2 cents,
> -Alex
>
>
>
> On 9/18/19, 9:45 AM, "Greg Dove"  wrote:
>
> 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 might think of as3 compile flag stuff. But perhaps
> there are ways to use some bitwise flag sets that evaluate to compile
> time
> constants (for GCC) to achieve some of the granular/selective content
> discrimination like I described with the hypothetical reflection
> optimization example. E.g framework vs non-framework/ UI vs. non-UI. I
> realise that all sounds complicated, which is why simple combos would
> be
> good for most people as Harbs mentioned.
>
> On Thu, 19 Sep 2019, 02:15 Harbs,  wrote:
>
> > Absolutely. Now we just need to figure out how… ;-)
> >
> > > On Sep 18, 2019, at 5:10 PM, Josh Tynjala <
> joshtynj...@bowlerhat.dev>
> > wrote:
> > >
> > >> I think the main thing we are 

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

[Alex Harui]

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 regular expressions in text and JS allows for it (at least so far).  
The compiler already has options to skip linking certain classes.  That syntax 
can be extended to skip or modify some of the JS for a class.  Also, the 
GoogDepsWriter reads just about every file already so doing more automated text 
manipulation is also "easy".

Also note that code-flow-analysis is also possible and may allow us to 
automatically/intelligently modify/remove code someday, so some of these 
options may be interim solutions.  For example, it might be possible to know 
which classes are being passed into Reflection and thus toss the reflection 
data from all of the other classes.

I haven't tried this, but I've also considered that instead of compile options 
that you can link in alternate SWCs with alternate code, or that will overwrite 
the prototype at runtime to alter how things behave.

Also, regarding public vars specifically, it may be that we use metadata to 
generate different code for vars.  We already do that with [Bindable].   It may 
be that if a class isn't a UI class and has [ClassAlias] or implements 
IExternalizable that we convert all vars to getter/setter (or do something else 
to prevent renaming) and that will the right default.  Or invent some new 
metadata to signal different var output.

In summary, large bucket options can be confusing, granular options can be 
painful, but we might be able to use code-flow or other hints and get it right 
more often than we do now.

My 2 cents,
-Alex



On 9/18/19, 9:45 AM, "Greg Dove"  wrote:

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 might think of as3 compile flag stuff. But perhaps
there are ways to use some bitwise flag sets that evaluate to compile time
constants (for GCC) to achieve some of the granular/selective content
discrimination like I described with the hypothetical reflection
optimization example. E.g framework vs non-framework/ UI vs. non-UI. I
realise that all sounds complicated, which is why simple combos would be
good for most people as Harbs mentioned.

On Thu, 19 Sep 2019, 02:15 Harbs,  wrote:

> 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 without recompiling
> > SWCs would be awesome. Without that control, we will continue to 
struggle
> > with differing opinions on how it should work.
> >
> > --
> > Josh Tynjala
> > Bowler Hat LLC 

> >
> >
> > On Wed, Sep 18, 2019 at 12:31 AM Greg Dove  wrote:
> >
> >> 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).

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

[Greg Dove]

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 might think of as3 compile flag stuff. But perhaps
there are ways to use some bitwise flag sets that evaluate to compile time
constants (for GCC) to achieve some of the granular/selective content
discrimination like I described with the hypothetical reflection
optimization example. E.g framework vs non-framework/ UI vs. non-UI. I
realise that all sounds complicated, which is why simple combos would be
good for most people as Harbs mentioned.

On Thu, 19 Sep 2019, 02:15 Harbs,  wrote:

> 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 without recompiling
> > SWCs would be awesome. Without that control, we will continue to struggle
> > with differing opinions on how it should work.
> >
> > --
> > Josh Tynjala
> > Bowler Hat LLC 
> >
> >
> > On Wed, Sep 18, 2019 at 12:31 AM Greg Dove  wrote:
> >
> >> 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  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  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 

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

[Harbs]

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 without recompiling
> SWCs would be awesome. Without that control, we will continue to struggle
> with differing opinions on how it should work.
> 
> --
> Josh Tynjala
> Bowler Hat LLC 
> 
> 
> On Wed, Sep 18, 2019 at 12:31 AM Greg Dove  wrote:
> 
>> 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  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  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 
>>> 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" 
>>> wrote:
> 
>   I was thinking about this some more, and is there anything else
>>> that's
>   public that also we allow to be 

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

[Josh Tynjala]

> 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 opinions on how it should work.

--
Josh Tynjala
Bowler Hat LLC 


On Wed, Sep 18, 2019 at 12:31 AM Greg Dove  wrote:

> 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  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  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 
> > 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" 
> > 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 

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

[Greg Dove]

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  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  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 
> 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" 
> 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.
> 

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

[Harbs]

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  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  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"  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.devdata=02%7C01%7Caharui%40adobe.com%7C384429ef197b497fff9408d73add9c25%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637042595795496907sdata=ii0taRMhu0bD0Ea577FNZ9CzDn%2B60MAdu7VsVIA92W4%3Dreserved=0
>>> 
>> 
>> 
>>On Mon, Sep 16, 2019 at 11:13 AM Josh Tynjala <
>> joshtynj...@bowlerhat.dev>
>>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.devdata=02%7C01%7Caharui%40adobe.com%7C384429ef197b497fff9408d73add9c25%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637042595795496907sdata=ii0taRMhu0bD0Ea577FNZ9CzDn%2B60MAdu7VsVIA92W4%3Dreserved=0
>>> 
>>> 
>>> 
>>> On Mon, Sep 16, 2019 at 10:50 AM Alex Harui >> 
>>> wrote:
>>> 
 I'm not sure I understand your proposal.  Are you proposing that all
 

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

[Greg Dove]

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  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"  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.devdata=02%7C01%7Caharui%40adobe.com%7C384429ef197b497fff9408d73add9c25%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637042595795496907sdata=ii0taRMhu0bD0Ea577FNZ9CzDn%2B60MAdu7VsVIA92W4%3Dreserved=0
> >
>
>
> On Mon, Sep 16, 2019 at 11:13 AM Josh Tynjala <
> joshtynj...@bowlerhat.dev>
> 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.devdata=02%7C01%7Caharui%40adobe.com%7C384429ef197b497fff9408d73add9c25%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637042595795496907sdata=ii0taRMhu0bD0Ea577FNZ9CzDn%2B60MAdu7VsVIA92W4%3Dreserved=0
> >
> >
> >
> > On Mon, Sep 16, 2019 at 10:50 AM Alex Harui  >
> > 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" 
> 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
> >> 

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

[Alex Harui]

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"  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 



On Mon, Sep 16, 2019 at 11:13 AM Josh Tynjala 
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 

>
>
> On Mon, Sep 16, 2019 at 10:50 AM Alex Harui 
> 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"  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 <
>> 

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

[Josh Tynjala]

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 


On Mon, Sep 16, 2019 at 11:13 AM Josh Tynjala 
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 
>
>
> On Mon, Sep 16, 2019 at 10:50 AM Alex Harui 
> 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"  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.devdata=02%7C01%7Caharui%40adobe.com%7Cbc8634d75ac34b1ff2a408d73acdc1c7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637042527741705917sdata=oIgajcsJSzyrmkeIOX%2BcuPe9lVt7iukyGAhrLdlVmvY%3Dreserved=0
>> >
>>
>>
>> On Mon, Sep 16, 2019 at 10:06 AM Alex Harui > >
>> 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" 
>> 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 <
>> >
>> 

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

[Josh Tynjala]

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 


On Mon, Sep 16, 2019 at 10:50 AM Alex Harui 
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"  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.devdata=02%7C01%7Caharui%40adobe.com%7Cbc8634d75ac34b1ff2a408d73acdc1c7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637042527741705917sdata=oIgajcsJSzyrmkeIOX%2BcuPe9lVt7iukyGAhrLdlVmvY%3Dreserved=0
> >
>
>
> On Mon, Sep 16, 2019 at 10:06 AM Alex Harui 
> 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" 
> 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.devdata=02%7C01%7Caharui%40adobe.com%7Cbc8634d75ac34b1ff2a408d73acdc1c7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637042527741715916sdata=RzTt0oXl8VlOFQx61iqQmpTnZjzRQ83WA0nhC14VaBU%3Dreserved=0
> > >
> >
> >
> > On Mon, Sep 16, 2019 at 9:54 AM Alex Harui
> 
> > 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 

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

[Alex Harui]

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"  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 



On Mon, Sep 16, 2019 at 10:06 AM Alex Harui 
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"  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.devdata=02%7C01%7Caharui%40adobe.com%7Cbc8634d75ac34b1ff2a408d73acdc1c7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637042527741715916sdata=RzTt0oXl8VlOFQx61iqQmpTnZjzRQ83WA0nhC14VaBU%3Dreserved=0
> >
>
>
> On Mon, Sep 16, 2019 at 9:54 AM Alex Harui 
> 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, 

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

[Josh Tynjala]

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 


On Mon, Sep 16, 2019 at 10:06 AM Alex Harui 
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"  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.devdata=02%7C01%7Caharui%40adobe.com%7Cd0c7fd54329c4f08a85708d73ac6ea33%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637042498316114014sdata=N30d559D3wJpJJ5%2BPNSp%2BLR5jg64caj3rCByjf41iyk%3Dreserved=0
> >
>
>
> On Mon, Sep 16, 2019 at 9:54 AM Alex Harui 
> 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" 
> 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%23nocollapsedata=02%7C01%7Caharui%40adobe.com%7Cd0c7fd54329c4f08a85708d73ac6ea33%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637042498316114014sdata=EyhgKMiOJL%2B7svlJUvqEb%2BWCC5J8ac5R2xPw2chkR3U%3Dreserved=0
> >
> > Isn't this collapsing behavior 

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

[Alex Harui]

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"  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 



On Mon, Sep 16, 2019 at 9:54 AM Alex Harui  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"  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%23nocollapsedata=02%7C01%7Caharui%40adobe.com%7Cd0c7fd54329c4f08a85708d73ac6ea33%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637042498316114014sdata=EyhgKMiOJL%2B7svlJUvqEb%2BWCC5J8ac5R2xPw2chkR3U%3Dreserved=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.devdata=02%7C01%7Caharui%40adobe.com%7Cd0c7fd54329c4f08a85708d73ac6ea33%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637042498316114014sdata=N30d559D3wJpJJ5%2BPNSp%2BLR5jg64caj3rCByjf41iyk%3Dreserved=0
> >
>
>
>

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

[Josh Tynjala]

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 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"  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%23nocollapsedata=02%7C01%7Caharui%40adobe.com%7C0444699041f3402d06c908d73abff16c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637042468374325733sdata=P%2FqQl7pq69YhAYtZQdKEHKnbgPuGDuD%2BikOca3aTOGY%3Dreserved=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.devdata=02%7C01%7Caharui%40adobe.com%7C0444699041f3402d06c908d73abff16c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637042468374335722sdata=%2BwzLkQRXkpBeaII1wYWrT1z4fb%2FqKt3Qn2O7q1K1j3w%3Dreserved=0
> >
>
>
>

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

[Alex Harui]

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"  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%23nocollapsedata=02%7C01%7Caharui%40adobe.com%7C0444699041f3402d06c908d73abff16c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637042468374325733sdata=P%2FqQl7pq69YhAYtZQdKEHKnbgPuGDuD%2BikOca3aTOGY%3Dreserved=0

Isn't this collapsing behavior the reason why we needed to add
-warn-public-vars?

--
Josh Tynjala
Bowler Hat LLC 

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

[Josh Tynjala]

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/Annotating-JavaScript-for-the-Closure-Compiler#nocollapse

Isn't this collapsing behavior the reason why we needed to add
-warn-public-vars?

--
Josh Tynjala
Bowler Hat LLC