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 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 <https://bowlerhat.dev>
>
>
> On Wed, Sep 18, 2019 at 12:31 AM Greg Dove <greg.d...@gmail.com> 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 <harbs.li...@gmail.com> 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 <greg.d...@gmail.com> 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 <aha...@adobe.com.invalid>
>>> 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" <joshtynj...@bowlerhat.dev>
>>> 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 <
>>>>> 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.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 <aha...@adobe.com.invalid
>>>>>>
>>>>>> 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" <joshtynj...@bowlerhat.dev>
>>>>> 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
>>>>> <aha...@adobe.com.invalid
>>>>>>>>
>>>>>>> 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" <
>>>>> joshtynj...@bowlerhat.dev>
>>>>>>> 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
>>>>>>> <aha...@adobe.com.invalid>
>>>>>>>> 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" <
>>>>>>> joshtynj...@bowlerhat.dev>
>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>
