You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@royale.apache.org by Alex Harui <ah...@adobe.com.INVALID> on 2018/02/20 17:26:27 UTC
Public Vars
Hi,
I just pushed compiler changes that will default to reporting a new
warning if you have public var in your Royale code. Public methods,
getters and setters are fine, but public vars do not handle minification.
I also just pushed a sweep of the framework code to eliminate public var
usage or add a directive to suppress the warning. At some point in time I
will probably sweep the examples, but I'm letting it spit a few warnings
for now. I hope to remove the * selector this week and that will require
another sweep of the examples.
Not using public vars should increase the changes that your minified code
will run. I put some information about public var usage in the wiki. I'm
not sure if or where it should go in the user doc. Users may be able
survive with more public vars since it mainly matters for vars used in
MXML, Binding, and States. But we want the framework to be clean, so if
you see a warning from your framework code, please clean it up.
https://github.com/apache/royale-asjs/wiki/Public-Variables
Thanks,
-Alex
Re: Public Vars
Posted by Alex Harui <ah...@adobe.com.INVALID>.
I'll look into it.
Get Outlook for Android<https://aka.ms/ghei36>
________________________________
From: Piotr Zarzycki <pi...@gmail.com>
Sent: Tuesday, February 20, 2018 12:50:12 PM
To: dev@royale.apache.org
Subject: Re: Public Vars
Alex,
What about with public vars in MXML which have [Bindable] ? - I'm getting
warrnings on such vars.
2018-02-20 20:19 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
> That might be an additional check someone could add to the compiler, but I
> don't think it solves the problem at the right time unless you have
> control over all of the code involved. I think the person who typed
> "public var" should be warned at the time they compile that line, not when
> someone tries to use it, potentially much later.
>
> If we added such a check, would it have helped you migrate your app?
> Especially given the check I just put in. Remember, you can disable the
> check I just put in for an entire SWC, an entire file, or each occurrence.
>
> -Alex
>
> On 2/20/18, 11:06 AM, "Gabe Harbs" <ha...@gmail.com> wrote:
>
> >For framework code which might be used in MXML, we’re probably going to
> >have to stick to setters and getters.
> >
> >For code which will not be used in MXML there’s no reason to not use
> >public vars (unless it needs setter/getter logic). I’m suggesting that if
> >Foo has some public var “baz”, and someone declares <local:Foo/>
> ><local:Foo baz=“true”/> would generate a compiler error that bar is not
> >set-able in MXML.
> >
> >Does that make sense?
> >
> >Harbs
> >
> >> On Feb 20, 2018, at 8:43 PM, Alex Harui <ah...@adobe.com.INVALID>
> >>wrote:
> >>
> >> I may not be understanding you, but the application developer likely
> >> didn't write the "public var" that is going to be a problem, some other
> >> component developer did. The goal is to get the component developer to
> >> not use public vars.
> >>
> >> Any application developer who uses MXMLComponents (an MXML file used as
> >>a
> >> component in another MXML file) is technically now a component developer
> >> and under the same restrictions.
> >>
> >> And as folks develop Royale apps with modules, they will face similar
> >> restrictions I think. I think we want to flag that. I don't think the
> >> contexts are limited to MXML, Binding, and States, nor does the
> >>framework
> >> component developer know the context when they type "public var".
> >>
> >> I did consider a flag that would have the JS output automatically
> >>generate
> >> a getter/setter for every public var. But that would significantly
> >>fatten
> >> your app for 700 public vars.
> >>
> >> Folks are welcome to try other options in the compiler. I just did what
> >> was quick and I think will help us help folks migrating.
> >>
> >> -Alex
> >>
> >> On 2/20/18, 10:30 AM, "Gabe Harbs" <harbs.lists@gmail.com
> >><ma...@gmail.com>> wrote:
> >>
> >>> What about a different approach?
> >>>
> >>> Maybe we can *disable* public vars in MXML, Binding and States?
> >>>
> >>> If someone tries to use public vars in those contexts, they would get a
> >>> compiler error. Only setters would show up as sett-able attributes in
> >>> MXML.
> >>>
> >>> If we can do that, we can probably get rid of @exports for pubic vars
> >>> which would probably make apps smaller.
> >>>
> >>> Thoughts?
> >>> Harbs
> >>>
> >>>> On Feb 20, 2018, at 8:23 PM, Alex Harui <ah...@adobe.com.INVALID>
> >>>> wrote:
> >>>>
> >>>> As a said, it mainly matters for MXML, Binding, and States.
> >>>>
> >>>> I believe it will matter in accessing modules and a module accessing
> >>>>the
> >>>> thing that loaded the module, and any other access by the original
> >>>> property name.
> >>>>
> >>>> I think it will matter in accessing Value Objects that are
> >>>>instantiated
> >>>> in
> >>>> the code instead of externally if that Value Object is not [Bindable].
> >>>> IOW, if you take some JSON and convert it to a plain Objects and tell
> >>>> the
> >>>> compiler that it is one of your Value Objects, that should work, but
> >>>>if
> >>>> you then create a new instance of a Value Object and set its
> >>>>properties
> >>>> in
> >>>> the code, I think that won't always work.
> >>>>
> >>>> Maybe we'll end up turning this flag off by default in MXMLC and on by
> >>>> default for COMPC or something like that. The goal is to catch places
> >>>> in
> >>>> the framework where it could matter to increase the chances that the
> >>>> js-release will work on the first try. The sweep definitely caught
> >>>>some
> >>>> things that needed to be changed. I might have suppressed some
> >>>>warnings
> >>>> on things that will need to be changed, not sure.
> >>>>
> >>>> Of course, I could be wrong...
> >>>> -Alex
> >>>>
> >>>> On 2/20/18, 10:07 AM, "Gabe Harbs" <harbs.lists@gmail.com
> >>>> <mailto:harbs.lists@gmail.com <ma...@gmail.com>>> wrote:
> >>>>
> >>>>> I have over 700 public vars in my app and it handles minification
> >>>>>just
> >>>>> fine.
> >>>>>
> >>>>> AFAIK, public vars are only a problem for classes and properties used
> >>>>> in
> >>>>> MXML. Am I wrong?
> >>>>>
> >>>>>> On Feb 20, 2018, at 7:26 PM, Alex Harui <aharui@adobe.com.INVALID
> >>>>>><ma...@adobe.com.INVALID>>
> >>>>>> wrote:
> >>>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> I just pushed compiler changes that will default to reporting a new
> >>>>>> warning if you have public var in your Royale code. Public methods,
> >>>>>> getters and setters are fine, but public vars do not handle
> >>>>>> minification.
> >>>>>>
> >>>>>> I also just pushed a sweep of the framework code to eliminate public
> >>>>>> var
> >>>>>> usage or add a directive to suppress the warning. At some point in
> >>>>>> time I
> >>>>>> will probably sweep the examples, but I'm letting it spit a few
> >>>>>> warnings
> >>>>>> for now. I hope to remove the * selector this week and that will
> >>>>>> require
> >>>>>> another sweep of the examples.
> >>>>>>
> >>>>>> Not using public vars should increase the changes that your minified
> >>>>>> code
> >>>>>> will run. I put some information about public var usage in the
> >>>>>>wiki.
> >>>>>> I'm
> >>>>>> not sure if or where it should go in the user doc. Users may be
> >>>>>>able
> >>>>>> survive with more public vars since it mainly matters for vars used
> >>>>>>in
> >>>>>> MXML, Binding, and States. But we want the framework to be clean,
> >>>>>>so
> >>>>>> if
> >>>>>> you see a warning from your framework code, please clean it up.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fgith
> >>>>>>ub
> >>>>>><https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fgit
> >>>>>>hub>
> >>>>>> .c
> >>>>>>
> >>>>>><https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fgit
> >>>>>>hu
> >>>>>><https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fgit
> >>>>>>hu>
> >>>>>> b.c>
> >>>>>>
> >>>>>>
> >>>>>>om%2Fapache%2Froyale-asjs%2Fwiki%2FPublic-
> Variables&data=02%7C01%7Cah
> >>>>>>ar
> >>>>>> ui
> >>>>>> %40adobe.com
> >>>>>><https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2F40ad
> >>>>>>obe.com%2F&data=02%7C01%7Caharui%40adobe.com%
> 7C9379c5d9afdd47b0c36a08
> >>>>>>d578950651%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C6365475038583
> >>>>>>21740&sdata=ubgCQCm%2FUcodcMc9MI2WSC5mB7Jl8lz5fOsw
> ErvtCUE%3D&reserved
> >>>>>>=0>
> >>>>>>
> >>>>>><https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2F40ad
> >>>>>>ob
> >>>>>><https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2F40ad
> >>>>>>ob>
> >>>>>> e.com
> >>>>>><https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fe.co
> >>>>>>m%2F&data=02%7C01%7Caharui%40adobe.com%
> 7C9379c5d9afdd47b0c36a08d57895
> >>>>>>0651%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636547503858321740&
> >>>>>>sdata=nSnpAaWec1c%2BCysE2AYM29t06IYWekNIv40rBVX8
> RWI%3D&reserved=0>%2F
> >>>>>>&data=02%7C01%7Caharui%40adobe.com
> >>>>>><https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2F40ad
> >>>>>>obe.com%2F&data=02%7C01%7Caharui%40adobe.com%
> 7C9379c5d9afdd47b0c36a08
> >>>>>>d578950651%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C6365475038583
> >>>>>>21740&sdata=ubgCQCm%2FUcodcMc9MI2WSC5mB7Jl8lz5fOsw
> ErvtCUE%3D&reserved
> >>>>>>=0>%7C9f0a4cdbb479423899b808d578
> >>>>>>
> >>>>>>901964%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C63654748277974730
> >>>>>>2&
> >>>>>>
> >>>>>>sdata=TS8usved8%2BQbV3pGRcza68UEn7VDF%2B2r1fEbN1UUKMo%3D&reserved=0>
> %
> >>>>>>7C
> >>>>>> 93e6c53f985c4a6ae7d408d5788cd84a%7Cfa7b1b5a7b34438794aed2c
> >>>>>>
> >>>>>>
> >>>>>>178decee1%7C0%7C0%7C636547468674049910&sdata=
> Vxx36hMI3fS1q8PT34WnMWln
> >>>>>>iF
> >>>>>> 3a
> >>>>>> LNONqTmEGghTUf0%3D&reserved=0
> >>>>>>
> >>>>>> Thanks,
> >>>>>> -Alex
> >
>
>
--
Piotr Zarzycki
Patreon: *https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C66d991afb14c4a01e97708d578a38f3f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636547566333215957&sdata=ui3lVDPVHEdU9x6X%2F1Q6VYbuv09%2FIveIH8dwFcbrPsI%3D&reserved=0
<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C66d991afb14c4a01e97708d578a38f3f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636547566333215957&sdata=ui3lVDPVHEdU9x6X%2F1Q6VYbuv09%2FIveIH8dwFcbrPsI%3D&reserved=0>*
Re: Public Vars
Posted by Piotr Zarzycki <pi...@gmail.com>.
Alex,
What about with public vars in MXML which have [Bindable] ? - I'm getting
warrnings on such vars.
2018-02-20 20:19 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
> That might be an additional check someone could add to the compiler, but I
> don't think it solves the problem at the right time unless you have
> control over all of the code involved. I think the person who typed
> "public var" should be warned at the time they compile that line, not when
> someone tries to use it, potentially much later.
>
> If we added such a check, would it have helped you migrate your app?
> Especially given the check I just put in. Remember, you can disable the
> check I just put in for an entire SWC, an entire file, or each occurrence.
>
> -Alex
>
> On 2/20/18, 11:06 AM, "Gabe Harbs" <ha...@gmail.com> wrote:
>
> >For framework code which might be used in MXML, we’re probably going to
> >have to stick to setters and getters.
> >
> >For code which will not be used in MXML there’s no reason to not use
> >public vars (unless it needs setter/getter logic). I’m suggesting that if
> >Foo has some public var “baz”, and someone declares <local:Foo/>
> ><local:Foo baz=“true”/> would generate a compiler error that bar is not
> >set-able in MXML.
> >
> >Does that make sense?
> >
> >Harbs
> >
> >> On Feb 20, 2018, at 8:43 PM, Alex Harui <ah...@adobe.com.INVALID>
> >>wrote:
> >>
> >> I may not be understanding you, but the application developer likely
> >> didn't write the "public var" that is going to be a problem, some other
> >> component developer did. The goal is to get the component developer to
> >> not use public vars.
> >>
> >> Any application developer who uses MXMLComponents (an MXML file used as
> >>a
> >> component in another MXML file) is technically now a component developer
> >> and under the same restrictions.
> >>
> >> And as folks develop Royale apps with modules, they will face similar
> >> restrictions I think. I think we want to flag that. I don't think the
> >> contexts are limited to MXML, Binding, and States, nor does the
> >>framework
> >> component developer know the context when they type "public var".
> >>
> >> I did consider a flag that would have the JS output automatically
> >>generate
> >> a getter/setter for every public var. But that would significantly
> >>fatten
> >> your app for 700 public vars.
> >>
> >> Folks are welcome to try other options in the compiler. I just did what
> >> was quick and I think will help us help folks migrating.
> >>
> >> -Alex
> >>
> >> On 2/20/18, 10:30 AM, "Gabe Harbs" <harbs.lists@gmail.com
> >><ma...@gmail.com>> wrote:
> >>
> >>> What about a different approach?
> >>>
> >>> Maybe we can *disable* public vars in MXML, Binding and States?
> >>>
> >>> If someone tries to use public vars in those contexts, they would get a
> >>> compiler error. Only setters would show up as sett-able attributes in
> >>> MXML.
> >>>
> >>> If we can do that, we can probably get rid of @exports for pubic vars
> >>> which would probably make apps smaller.
> >>>
> >>> Thoughts?
> >>> Harbs
> >>>
> >>>> On Feb 20, 2018, at 8:23 PM, Alex Harui <ah...@adobe.com.INVALID>
> >>>> wrote:
> >>>>
> >>>> As a said, it mainly matters for MXML, Binding, and States.
> >>>>
> >>>> I believe it will matter in accessing modules and a module accessing
> >>>>the
> >>>> thing that loaded the module, and any other access by the original
> >>>> property name.
> >>>>
> >>>> I think it will matter in accessing Value Objects that are
> >>>>instantiated
> >>>> in
> >>>> the code instead of externally if that Value Object is not [Bindable].
> >>>> IOW, if you take some JSON and convert it to a plain Objects and tell
> >>>> the
> >>>> compiler that it is one of your Value Objects, that should work, but
> >>>>if
> >>>> you then create a new instance of a Value Object and set its
> >>>>properties
> >>>> in
> >>>> the code, I think that won't always work.
> >>>>
> >>>> Maybe we'll end up turning this flag off by default in MXMLC and on by
> >>>> default for COMPC or something like that. The goal is to catch places
> >>>> in
> >>>> the framework where it could matter to increase the chances that the
> >>>> js-release will work on the first try. The sweep definitely caught
> >>>>some
> >>>> things that needed to be changed. I might have suppressed some
> >>>>warnings
> >>>> on things that will need to be changed, not sure.
> >>>>
> >>>> Of course, I could be wrong...
> >>>> -Alex
> >>>>
> >>>> On 2/20/18, 10:07 AM, "Gabe Harbs" <harbs.lists@gmail.com
> >>>> <mailto:harbs.lists@gmail.com <ma...@gmail.com>>> wrote:
> >>>>
> >>>>> I have over 700 public vars in my app and it handles minification
> >>>>>just
> >>>>> fine.
> >>>>>
> >>>>> AFAIK, public vars are only a problem for classes and properties used
> >>>>> in
> >>>>> MXML. Am I wrong?
> >>>>>
> >>>>>> On Feb 20, 2018, at 7:26 PM, Alex Harui <aharui@adobe.com.INVALID
> >>>>>><ma...@adobe.com.INVALID>>
> >>>>>> wrote:
> >>>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> I just pushed compiler changes that will default to reporting a new
> >>>>>> warning if you have public var in your Royale code. Public methods,
> >>>>>> getters and setters are fine, but public vars do not handle
> >>>>>> minification.
> >>>>>>
> >>>>>> I also just pushed a sweep of the framework code to eliminate public
> >>>>>> var
> >>>>>> usage or add a directive to suppress the warning. At some point in
> >>>>>> time I
> >>>>>> will probably sweep the examples, but I'm letting it spit a few
> >>>>>> warnings
> >>>>>> for now. I hope to remove the * selector this week and that will
> >>>>>> require
> >>>>>> another sweep of the examples.
> >>>>>>
> >>>>>> Not using public vars should increase the changes that your minified
> >>>>>> code
> >>>>>> will run. I put some information about public var usage in the
> >>>>>>wiki.
> >>>>>> I'm
> >>>>>> not sure if or where it should go in the user doc. Users may be
> >>>>>>able
> >>>>>> survive with more public vars since it mainly matters for vars used
> >>>>>>in
> >>>>>> MXML, Binding, and States. But we want the framework to be clean,
> >>>>>>so
> >>>>>> if
> >>>>>> you see a warning from your framework code, please clean it up.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fgith
> >>>>>>ub
> >>>>>><https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fgit
> >>>>>>hub>
> >>>>>> .c
> >>>>>>
> >>>>>><https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fgit
> >>>>>>hu
> >>>>>><https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fgit
> >>>>>>hu>
> >>>>>> b.c>
> >>>>>>
> >>>>>>
> >>>>>>om%2Fapache%2Froyale-asjs%2Fwiki%2FPublic-
> Variables&data=02%7C01%7Cah
> >>>>>>ar
> >>>>>> ui
> >>>>>> %40adobe.com
> >>>>>><https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2F40ad
> >>>>>>obe.com%2F&data=02%7C01%7Caharui%40adobe.com%
> 7C9379c5d9afdd47b0c36a08
> >>>>>>d578950651%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C6365475038583
> >>>>>>21740&sdata=ubgCQCm%2FUcodcMc9MI2WSC5mB7Jl8lz5fOsw
> ErvtCUE%3D&reserved
> >>>>>>=0>
> >>>>>>
> >>>>>><https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2F40ad
> >>>>>>ob
> >>>>>><https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2F40ad
> >>>>>>ob>
> >>>>>> e.com
> >>>>>><https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fe.co
> >>>>>>m%2F&data=02%7C01%7Caharui%40adobe.com%
> 7C9379c5d9afdd47b0c36a08d57895
> >>>>>>0651%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636547503858321740&
> >>>>>>sdata=nSnpAaWec1c%2BCysE2AYM29t06IYWekNIv40rBVX8
> RWI%3D&reserved=0>%2F
> >>>>>>&data=02%7C01%7Caharui%40adobe.com
> >>>>>><https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2F40ad
> >>>>>>obe.com%2F&data=02%7C01%7Caharui%40adobe.com%
> 7C9379c5d9afdd47b0c36a08
> >>>>>>d578950651%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C6365475038583
> >>>>>>21740&sdata=ubgCQCm%2FUcodcMc9MI2WSC5mB7Jl8lz5fOsw
> ErvtCUE%3D&reserved
> >>>>>>=0>%7C9f0a4cdbb479423899b808d578
> >>>>>>
> >>>>>>901964%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C63654748277974730
> >>>>>>2&
> >>>>>>
> >>>>>>sdata=TS8usved8%2BQbV3pGRcza68UEn7VDF%2B2r1fEbN1UUKMo%3D&reserved=0>
> %
> >>>>>>7C
> >>>>>> 93e6c53f985c4a6ae7d408d5788cd84a%7Cfa7b1b5a7b34438794aed2c
> >>>>>>
> >>>>>>
> >>>>>>178decee1%7C0%7C0%7C636547468674049910&sdata=
> Vxx36hMI3fS1q8PT34WnMWln
> >>>>>>iF
> >>>>>> 3a
> >>>>>> LNONqTmEGghTUf0%3D&reserved=0
> >>>>>>
> >>>>>> Thanks,
> >>>>>> -Alex
> >
>
>
--
Piotr Zarzycki
Patreon: *https://www.patreon.com/piotrzarzycki
<https://www.patreon.com/piotrzarzycki>*
Re: Public Vars
Posted by Alex Harui <ah...@adobe.com.INVALID>.
That might be an additional check someone could add to the compiler, but I
don't think it solves the problem at the right time unless you have
control over all of the code involved. I think the person who typed
"public var" should be warned at the time they compile that line, not when
someone tries to use it, potentially much later.
If we added such a check, would it have helped you migrate your app?
Especially given the check I just put in. Remember, you can disable the
check I just put in for an entire SWC, an entire file, or each occurrence.
-Alex
On 2/20/18, 11:06 AM, "Gabe Harbs" <ha...@gmail.com> wrote:
>For framework code which might be used in MXML, we’re probably going to
>have to stick to setters and getters.
>
>For code which will not be used in MXML there’s no reason to not use
>public vars (unless it needs setter/getter logic). I’m suggesting that if
>Foo has some public var “baz”, and someone declares <local:Foo/>
><local:Foo baz=“true”/> would generate a compiler error that bar is not
>set-able in MXML.
>
>Does that make sense?
>
>Harbs
>
>> On Feb 20, 2018, at 8:43 PM, Alex Harui <ah...@adobe.com.INVALID>
>>wrote:
>>
>> I may not be understanding you, but the application developer likely
>> didn't write the "public var" that is going to be a problem, some other
>> component developer did. The goal is to get the component developer to
>> not use public vars.
>>
>> Any application developer who uses MXMLComponents (an MXML file used as
>>a
>> component in another MXML file) is technically now a component developer
>> and under the same restrictions.
>>
>> And as folks develop Royale apps with modules, they will face similar
>> restrictions I think. I think we want to flag that. I don't think the
>> contexts are limited to MXML, Binding, and States, nor does the
>>framework
>> component developer know the context when they type "public var".
>>
>> I did consider a flag that would have the JS output automatically
>>generate
>> a getter/setter for every public var. But that would significantly
>>fatten
>> your app for 700 public vars.
>>
>> Folks are welcome to try other options in the compiler. I just did what
>> was quick and I think will help us help folks migrating.
>>
>> -Alex
>>
>> On 2/20/18, 10:30 AM, "Gabe Harbs" <harbs.lists@gmail.com
>><ma...@gmail.com>> wrote:
>>
>>> What about a different approach?
>>>
>>> Maybe we can *disable* public vars in MXML, Binding and States?
>>>
>>> If someone tries to use public vars in those contexts, they would get a
>>> compiler error. Only setters would show up as sett-able attributes in
>>> MXML.
>>>
>>> If we can do that, we can probably get rid of @exports for pubic vars
>>> which would probably make apps smaller.
>>>
>>> Thoughts?
>>> Harbs
>>>
>>>> On Feb 20, 2018, at 8:23 PM, Alex Harui <ah...@adobe.com.INVALID>
>>>> wrote:
>>>>
>>>> As a said, it mainly matters for MXML, Binding, and States.
>>>>
>>>> I believe it will matter in accessing modules and a module accessing
>>>>the
>>>> thing that loaded the module, and any other access by the original
>>>> property name.
>>>>
>>>> I think it will matter in accessing Value Objects that are
>>>>instantiated
>>>> in
>>>> the code instead of externally if that Value Object is not [Bindable].
>>>> IOW, if you take some JSON and convert it to a plain Objects and tell
>>>> the
>>>> compiler that it is one of your Value Objects, that should work, but
>>>>if
>>>> you then create a new instance of a Value Object and set its
>>>>properties
>>>> in
>>>> the code, I think that won't always work.
>>>>
>>>> Maybe we'll end up turning this flag off by default in MXMLC and on by
>>>> default for COMPC or something like that. The goal is to catch places
>>>> in
>>>> the framework where it could matter to increase the chances that the
>>>> js-release will work on the first try. The sweep definitely caught
>>>>some
>>>> things that needed to be changed. I might have suppressed some
>>>>warnings
>>>> on things that will need to be changed, not sure.
>>>>
>>>> Of course, I could be wrong...
>>>> -Alex
>>>>
>>>> On 2/20/18, 10:07 AM, "Gabe Harbs" <harbs.lists@gmail.com
>>>> <mailto:harbs.lists@gmail.com <ma...@gmail.com>>> wrote:
>>>>
>>>>> I have over 700 public vars in my app and it handles minification
>>>>>just
>>>>> fine.
>>>>>
>>>>> AFAIK, public vars are only a problem for classes and properties used
>>>>> in
>>>>> MXML. Am I wrong?
>>>>>
>>>>>> On Feb 20, 2018, at 7:26 PM, Alex Harui <aharui@adobe.com.INVALID
>>>>>><ma...@adobe.com.INVALID>>
>>>>>> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I just pushed compiler changes that will default to reporting a new
>>>>>> warning if you have public var in your Royale code. Public methods,
>>>>>> getters and setters are fine, but public vars do not handle
>>>>>> minification.
>>>>>>
>>>>>> I also just pushed a sweep of the framework code to eliminate public
>>>>>> var
>>>>>> usage or add a directive to suppress the warning. At some point in
>>>>>> time I
>>>>>> will probably sweep the examples, but I'm letting it spit a few
>>>>>> warnings
>>>>>> for now. I hope to remove the * selector this week and that will
>>>>>> require
>>>>>> another sweep of the examples.
>>>>>>
>>>>>> Not using public vars should increase the changes that your minified
>>>>>> code
>>>>>> will run. I put some information about public var usage in the
>>>>>>wiki.
>>>>>> I'm
>>>>>> not sure if or where it should go in the user doc. Users may be
>>>>>>able
>>>>>> survive with more public vars since it mainly matters for vars used
>>>>>>in
>>>>>> MXML, Binding, and States. But we want the framework to be clean,
>>>>>>so
>>>>>> if
>>>>>> you see a warning from your framework code, please clean it up.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
>>>>>>ub
>>>>>><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
>>>>>>hub>
>>>>>> .c
>>>>>>
>>>>>><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
>>>>>>hu
>>>>>><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
>>>>>>hu>
>>>>>> b.c>
>>>>>>
>>>>>>
>>>>>>om%2Fapache%2Froyale-asjs%2Fwiki%2FPublic-Variables&data=02%7C01%7Cah
>>>>>>ar
>>>>>> ui
>>>>>> %40adobe.com
>>>>>><https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2F40ad
>>>>>>obe.com%2F&data=02%7C01%7Caharui%40adobe.com%7C9379c5d9afdd47b0c36a08
>>>>>>d578950651%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6365475038583
>>>>>>21740&sdata=ubgCQCm%2FUcodcMc9MI2WSC5mB7Jl8lz5fOswErvtCUE%3D&reserved
>>>>>>=0>
>>>>>>
>>>>>><https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2F40ad
>>>>>>ob
>>>>>><https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2F40ad
>>>>>>ob>
>>>>>> e.com
>>>>>><https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fe.co
>>>>>>m%2F&data=02%7C01%7Caharui%40adobe.com%7C9379c5d9afdd47b0c36a08d57895
>>>>>>0651%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636547503858321740&
>>>>>>sdata=nSnpAaWec1c%2BCysE2AYM29t06IYWekNIv40rBVX8RWI%3D&reserved=0>%2F
>>>>>>&data=02%7C01%7Caharui%40adobe.com
>>>>>><https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2F40ad
>>>>>>obe.com%2F&data=02%7C01%7Caharui%40adobe.com%7C9379c5d9afdd47b0c36a08
>>>>>>d578950651%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6365475038583
>>>>>>21740&sdata=ubgCQCm%2FUcodcMc9MI2WSC5mB7Jl8lz5fOswErvtCUE%3D&reserved
>>>>>>=0>%7C9f0a4cdbb479423899b808d578
>>>>>>
>>>>>>901964%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63654748277974730
>>>>>>2&
>>>>>>
>>>>>>sdata=TS8usved8%2BQbV3pGRcza68UEn7VDF%2B2r1fEbN1UUKMo%3D&reserved=0>%
>>>>>>7C
>>>>>> 93e6c53f985c4a6ae7d408d5788cd84a%7Cfa7b1b5a7b34438794aed2c
>>>>>>
>>>>>>
>>>>>>178decee1%7C0%7C0%7C636547468674049910&sdata=Vxx36hMI3fS1q8PT34WnMWln
>>>>>>iF
>>>>>> 3a
>>>>>> LNONqTmEGghTUf0%3D&reserved=0
>>>>>>
>>>>>> Thanks,
>>>>>> -Alex
>
Re: Public Vars
Posted by Gabe Harbs <ha...@gmail.com>.
For framework code which might be used in MXML, we’re probably going to have to stick to setters and getters.
For code which will not be used in MXML there’s no reason to not use public vars (unless it needs setter/getter logic). I’m suggesting that if Foo has some public var “baz”, and someone declares <local:Foo/> <local:Foo baz=“true”/> would generate a compiler error that bar is not set-able in MXML.
Does that make sense?
Harbs
> On Feb 20, 2018, at 8:43 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> I may not be understanding you, but the application developer likely
> didn't write the "public var" that is going to be a problem, some other
> component developer did. The goal is to get the component developer to
> not use public vars.
>
> Any application developer who uses MXMLComponents (an MXML file used as a
> component in another MXML file) is technically now a component developer
> and under the same restrictions.
>
> And as folks develop Royale apps with modules, they will face similar
> restrictions I think. I think we want to flag that. I don't think the
> contexts are limited to MXML, Binding, and States, nor does the framework
> component developer know the context when they type "public var".
>
> I did consider a flag that would have the JS output automatically generate
> a getter/setter for every public var. But that would significantly fatten
> your app for 700 public vars.
>
> Folks are welcome to try other options in the compiler. I just did what
> was quick and I think will help us help folks migrating.
>
> -Alex
>
> On 2/20/18, 10:30 AM, "Gabe Harbs" <harbs.lists@gmail.com <ma...@gmail.com>> wrote:
>
>> What about a different approach?
>>
>> Maybe we can *disable* public vars in MXML, Binding and States?
>>
>> If someone tries to use public vars in those contexts, they would get a
>> compiler error. Only setters would show up as sett-able attributes in
>> MXML.
>>
>> If we can do that, we can probably get rid of @exports for pubic vars
>> which would probably make apps smaller.
>>
>> Thoughts?
>> Harbs
>>
>>> On Feb 20, 2018, at 8:23 PM, Alex Harui <ah...@adobe.com.INVALID>
>>> wrote:
>>>
>>> As a said, it mainly matters for MXML, Binding, and States.
>>>
>>> I believe it will matter in accessing modules and a module accessing the
>>> thing that loaded the module, and any other access by the original
>>> property name.
>>>
>>> I think it will matter in accessing Value Objects that are instantiated
>>> in
>>> the code instead of externally if that Value Object is not [Bindable].
>>> IOW, if you take some JSON and convert it to a plain Objects and tell
>>> the
>>> compiler that it is one of your Value Objects, that should work, but if
>>> you then create a new instance of a Value Object and set its properties
>>> in
>>> the code, I think that won't always work.
>>>
>>> Maybe we'll end up turning this flag off by default in MXMLC and on by
>>> default for COMPC or something like that. The goal is to catch places
>>> in
>>> the framework where it could matter to increase the chances that the
>>> js-release will work on the first try. The sweep definitely caught some
>>> things that needed to be changed. I might have suppressed some warnings
>>> on things that will need to be changed, not sure.
>>>
>>> Of course, I could be wrong...
>>> -Alex
>>>
>>> On 2/20/18, 10:07 AM, "Gabe Harbs" <harbs.lists@gmail.com
>>> <mailto:harbs.lists@gmail.com <ma...@gmail.com>>> wrote:
>>>
>>>> I have over 700 public vars in my app and it handles minification just
>>>> fine.
>>>>
>>>> AFAIK, public vars are only a problem for classes and properties used
>>>> in
>>>> MXML. Am I wrong?
>>>>
>>>>> On Feb 20, 2018, at 7:26 PM, Alex Harui <aharui@adobe.com.INVALID <ma...@adobe.com.INVALID>>
>>>>> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I just pushed compiler changes that will default to reporting a new
>>>>> warning if you have public var in your Royale code. Public methods,
>>>>> getters and setters are fine, but public vars do not handle
>>>>> minification.
>>>>>
>>>>> I also just pushed a sweep of the framework code to eliminate public
>>>>> var
>>>>> usage or add a directive to suppress the warning. At some point in
>>>>> time I
>>>>> will probably sweep the examples, but I'm letting it spit a few
>>>>> warnings
>>>>> for now. I hope to remove the * selector this week and that will
>>>>> require
>>>>> another sweep of the examples.
>>>>>
>>>>> Not using public vars should increase the changes that your minified
>>>>> code
>>>>> will run. I put some information about public var usage in the wiki.
>>>>> I'm
>>>>> not sure if or where it should go in the user doc. Users may be able
>>>>> survive with more public vars since it mainly matters for vars used in
>>>>> MXML, Binding, and States. But we want the framework to be clean, so
>>>>> if
>>>>> you see a warning from your framework code, please clean it up.
>>>>>
>>>>>
>>>>>
>>>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub>
>>>>> .c
>>>>> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu>
>>>>> b.c>
>>>>>
>>>>> om%2Fapache%2Froyale-asjs%2Fwiki%2FPublic-Variables&data=02%7C01%7Cahar
>>>>> ui
>>>>> %40adobe.com <http://40adobe.com/>
>>>>> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2F40adob <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2F40adob>
>>>>> e.com <http://e.com/>%2F&data=02%7C01%7Caharui%40adobe.com <http://40adobe.com/>%7C9f0a4cdbb479423899b808d578
>>>>> 901964%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636547482779747302&
>>>>> sdata=TS8usved8%2BQbV3pGRcza68UEn7VDF%2B2r1fEbN1UUKMo%3D&reserved=0>%7C
>>>>> 93e6c53f985c4a6ae7d408d5788cd84a%7Cfa7b1b5a7b34438794aed2c
>>>>>
>>>>> 178decee1%7C0%7C0%7C636547468674049910&sdata=Vxx36hMI3fS1q8PT34WnMWlniF
>>>>> 3a
>>>>> LNONqTmEGghTUf0%3D&reserved=0
>>>>>
>>>>> Thanks,
>>>>> -Alex
Re: Public Vars
Posted by Alex Harui <ah...@adobe.com.INVALID>.
I may not be understanding you, but the application developer likely
didn't write the "public var" that is going to be a problem, some other
component developer did. The goal is to get the component developer to
not use public vars.
Any application developer who uses MXMLComponents (an MXML file used as a
component in another MXML file) is technically now a component developer
and under the same restrictions.
And as folks develop Royale apps with modules, they will face similar
restrictions I think. I think we want to flag that. I don't think the
contexts are limited to MXML, Binding, and States, nor does the framework
component developer know the context when they type "public var".
I did consider a flag that would have the JS output automatically generate
a getter/setter for every public var. But that would significantly fatten
your app for 700 public vars.
Folks are welcome to try other options in the compiler. I just did what
was quick and I think will help us help folks migrating.
-Alex
On 2/20/18, 10:30 AM, "Gabe Harbs" <ha...@gmail.com> wrote:
>What about a different approach?
>
>Maybe we can *disable* public vars in MXML, Binding and States?
>
>If someone tries to use public vars in those contexts, they would get a
>compiler error. Only setters would show up as sett-able attributes in
>MXML.
>
>If we can do that, we can probably get rid of @exports for pubic vars
>which would probably make apps smaller.
>
>Thoughts?
>Harbs
>
>> On Feb 20, 2018, at 8:23 PM, Alex Harui <ah...@adobe.com.INVALID>
>>wrote:
>>
>> As a said, it mainly matters for MXML, Binding, and States.
>>
>> I believe it will matter in accessing modules and a module accessing the
>> thing that loaded the module, and any other access by the original
>> property name.
>>
>> I think it will matter in accessing Value Objects that are instantiated
>>in
>> the code instead of externally if that Value Object is not [Bindable].
>> IOW, if you take some JSON and convert it to a plain Objects and tell
>>the
>> compiler that it is one of your Value Objects, that should work, but if
>> you then create a new instance of a Value Object and set its properties
>>in
>> the code, I think that won't always work.
>>
>> Maybe we'll end up turning this flag off by default in MXMLC and on by
>> default for COMPC or something like that. The goal is to catch places
>>in
>> the framework where it could matter to increase the chances that the
>> js-release will work on the first try. The sweep definitely caught some
>> things that needed to be changed. I might have suppressed some warnings
>> on things that will need to be changed, not sure.
>>
>> Of course, I could be wrong...
>> -Alex
>>
>> On 2/20/18, 10:07 AM, "Gabe Harbs" <harbs.lists@gmail.com
>><ma...@gmail.com>> wrote:
>>
>>> I have over 700 public vars in my app and it handles minification just
>>> fine.
>>>
>>> AFAIK, public vars are only a problem for classes and properties used
>>>in
>>> MXML. Am I wrong?
>>>
>>>> On Feb 20, 2018, at 7:26 PM, Alex Harui <ah...@adobe.com.INVALID>
>>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> I just pushed compiler changes that will default to reporting a new
>>>> warning if you have public var in your Royale code. Public methods,
>>>> getters and setters are fine, but public vars do not handle
>>>> minification.
>>>>
>>>> I also just pushed a sweep of the framework code to eliminate public
>>>>var
>>>> usage or add a directive to suppress the warning. At some point in
>>>> time I
>>>> will probably sweep the examples, but I'm letting it spit a few
>>>>warnings
>>>> for now. I hope to remove the * selector this week and that will
>>>> require
>>>> another sweep of the examples.
>>>>
>>>> Not using public vars should increase the changes that your minified
>>>> code
>>>> will run. I put some information about public var usage in the wiki.
>>>> I'm
>>>> not sure if or where it should go in the user doc. Users may be able
>>>> survive with more public vars since it mainly matters for vars used in
>>>> MXML, Binding, and States. But we want the framework to be clean, so
>>>>if
>>>> you see a warning from your framework code, please clean it up.
>>>>
>>>>
>>>>
>>>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub
>>>>.c
>>>><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu
>>>>b.c>
>>>>
>>>>om%2Fapache%2Froyale-asjs%2Fwiki%2FPublic-Variables&data=02%7C01%7Cahar
>>>>ui
>>>> %40adobe.com
>>>><https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2F40adob
>>>>e.com%2F&data=02%7C01%7Caharui%40adobe.com%7C9f0a4cdbb479423899b808d578
>>>>901964%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636547482779747302&
>>>>sdata=TS8usved8%2BQbV3pGRcza68UEn7VDF%2B2r1fEbN1UUKMo%3D&reserved=0>%7C
>>>>93e6c53f985c4a6ae7d408d5788cd84a%7Cfa7b1b5a7b34438794aed2c
>>>>
>>>>178decee1%7C0%7C0%7C636547468674049910&sdata=Vxx36hMI3fS1q8PT34WnMWlniF
>>>>3a
>>>> LNONqTmEGghTUf0%3D&reserved=0
>>>>
>>>> Thanks,
>>>> -Alex
>
Re: Public Vars
Posted by Gabe Harbs <ha...@gmail.com>.
What about a different approach?
Maybe we can *disable* public vars in MXML, Binding and States?
If someone tries to use public vars in those contexts, they would get a compiler error. Only setters would show up as sett-able attributes in MXML.
If we can do that, we can probably get rid of @exports for pubic vars which would probably make apps smaller.
Thoughts?
Harbs
> On Feb 20, 2018, at 8:23 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> As a said, it mainly matters for MXML, Binding, and States.
>
> I believe it will matter in accessing modules and a module accessing the
> thing that loaded the module, and any other access by the original
> property name.
>
> I think it will matter in accessing Value Objects that are instantiated in
> the code instead of externally if that Value Object is not [Bindable].
> IOW, if you take some JSON and convert it to a plain Objects and tell the
> compiler that it is one of your Value Objects, that should work, but if
> you then create a new instance of a Value Object and set its properties in
> the code, I think that won't always work.
>
> Maybe we'll end up turning this flag off by default in MXMLC and on by
> default for COMPC or something like that. The goal is to catch places in
> the framework where it could matter to increase the chances that the
> js-release will work on the first try. The sweep definitely caught some
> things that needed to be changed. I might have suppressed some warnings
> on things that will need to be changed, not sure.
>
> Of course, I could be wrong...
> -Alex
>
> On 2/20/18, 10:07 AM, "Gabe Harbs" <harbs.lists@gmail.com <ma...@gmail.com>> wrote:
>
>> I have over 700 public vars in my app and it handles minification just
>> fine.
>>
>> AFAIK, public vars are only a problem for classes and properties used in
>> MXML. Am I wrong?
>>
>>> On Feb 20, 2018, at 7:26 PM, Alex Harui <ah...@adobe.com.INVALID>
>>> wrote:
>>>
>>> Hi,
>>>
>>> I just pushed compiler changes that will default to reporting a new
>>> warning if you have public var in your Royale code. Public methods,
>>> getters and setters are fine, but public vars do not handle
>>> minification.
>>>
>>> I also just pushed a sweep of the framework code to eliminate public var
>>> usage or add a directive to suppress the warning. At some point in
>>> time I
>>> will probably sweep the examples, but I'm letting it spit a few warnings
>>> for now. I hope to remove the * selector this week and that will
>>> require
>>> another sweep of the examples.
>>>
>>> Not using public vars should increase the changes that your minified
>>> code
>>> will run. I put some information about public var usage in the wiki.
>>> I'm
>>> not sure if or where it should go in the user doc. Users may be able
>>> survive with more public vars since it mainly matters for vars used in
>>> MXML, Binding, and States. But we want the framework to be clean, so if
>>> you see a warning from your framework code, please clean it up.
>>>
>>>
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c>
>>> om%2Fapache%2Froyale-asjs%2Fwiki%2FPublic-Variables&data=02%7C01%7Caharui
>>> %40adobe.com <http://40adobe.com/>%7C93e6c53f985c4a6ae7d408d5788cd84a%7Cfa7b1b5a7b34438794aed2c
>>> 178decee1%7C0%7C0%7C636547468674049910&sdata=Vxx36hMI3fS1q8PT34WnMWlniF3a
>>> LNONqTmEGghTUf0%3D&reserved=0
>>>
>>> Thanks,
>>> -Alex
Re: Public Vars
Posted by Alex Harui <ah...@adobe.com.INVALID>.
As a said, it mainly matters for MXML, Binding, and States.
I believe it will matter in accessing modules and a module accessing the
thing that loaded the module, and any other access by the original
property name.
I think it will matter in accessing Value Objects that are instantiated in
the code instead of externally if that Value Object is not [Bindable].
IOW, if you take some JSON and convert it to a plain Objects and tell the
compiler that it is one of your Value Objects, that should work, but if
you then create a new instance of a Value Object and set its properties in
the code, I think that won't always work.
Maybe we'll end up turning this flag off by default in MXMLC and on by
default for COMPC or something like that. The goal is to catch places in
the framework where it could matter to increase the chances that the
js-release will work on the first try. The sweep definitely caught some
things that needed to be changed. I might have suppressed some warnings
on things that will need to be changed, not sure.
Of course, I could be wrong...
-Alex
On 2/20/18, 10:07 AM, "Gabe Harbs" <ha...@gmail.com> wrote:
>I have over 700 public vars in my app and it handles minification just
>fine.
>
>AFAIK, public vars are only a problem for classes and properties used in
>MXML. Am I wrong?
>
>> On Feb 20, 2018, at 7:26 PM, Alex Harui <ah...@adobe.com.INVALID>
>>wrote:
>>
>> Hi,
>>
>> I just pushed compiler changes that will default to reporting a new
>> warning if you have public var in your Royale code. Public methods,
>> getters and setters are fine, but public vars do not handle
>>minification.
>>
>> I also just pushed a sweep of the framework code to eliminate public var
>> usage or add a directive to suppress the warning. At some point in
>>time I
>> will probably sweep the examples, but I'm letting it spit a few warnings
>> for now. I hope to remove the * selector this week and that will
>>require
>> another sweep of the examples.
>>
>> Not using public vars should increase the changes that your minified
>>code
>> will run. I put some information about public var usage in the wiki.
>>I'm
>> not sure if or where it should go in the user doc. Users may be able
>> survive with more public vars since it mainly matters for vars used in
>> MXML, Binding, and States. But we want the framework to be clean, so if
>> you see a warning from your framework code, please clean it up.
>>
>>
>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c
>>om%2Fapache%2Froyale-asjs%2Fwiki%2FPublic-Variables&data=02%7C01%7Caharui
>>%40adobe.com%7C93e6c53f985c4a6ae7d408d5788cd84a%7Cfa7b1b5a7b34438794aed2c
>>178decee1%7C0%7C0%7C636547468674049910&sdata=Vxx36hMI3fS1q8PT34WnMWlniF3a
>>LNONqTmEGghTUf0%3D&reserved=0
>>
>> Thanks,
>> -Alex
>>
>
Re: Public Vars
Posted by Gabe Harbs <ha...@gmail.com>.
I have over 700 public vars in my app and it handles minification just fine.
AFAIK, public vars are only a problem for classes and properties used in MXML. Am I wrong?
> On Feb 20, 2018, at 7:26 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> Hi,
>
> I just pushed compiler changes that will default to reporting a new
> warning if you have public var in your Royale code. Public methods,
> getters and setters are fine, but public vars do not handle minification.
>
> I also just pushed a sweep of the framework code to eliminate public var
> usage or add a directive to suppress the warning. At some point in time I
> will probably sweep the examples, but I'm letting it spit a few warnings
> for now. I hope to remove the * selector this week and that will require
> another sweep of the examples.
>
> Not using public vars should increase the changes that your minified code
> will run. I put some information about public var usage in the wiki. I'm
> not sure if or where it should go in the user doc. Users may be able
> survive with more public vars since it mainly matters for vars used in
> MXML, Binding, and States. But we want the framework to be clean, so if
> you see a warning from your framework code, please clean it up.
>
> https://github.com/apache/royale-asjs/wiki/Public-Variables
>
> Thanks,
> -Alex
>
Re: Public Vars
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Yes, you are correct. So I suppose it will be a migration issue. I'll be
interested to see how prevalent it is "in the wild". If you have a public
var with [Bindable], that should be ok and the Royale compiler will not
warn on [Bindable] public vars. They are converted to getter/setters and
thus are immune from minification. In theory most folks used public vars
in Value Objects and made them [Bindable], but I have seen that folks just
ignored the warning from the compiler that there was a binding to a
non-bindable variable.
Thanks,
-Alex
On 2/20/18, 9:39 AM, "Andrew Wetmore" <co...@gmail.com> wrote:
>Am I right that public vars were no problem in apps compiled for Flash or
>AIR use, and that this improvement relates to creating a Royale app for JS
>production?
>
><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.avas
>t.com%2Fsig-email%3Futm_medium%3Demail%26utm_source%3Dlink%26utm_campaign%
>3Dsig-email%26utm_content%3Dwebmail&data=02%7C01%7Caharui%40adobe.com%7C00
>be1125ff064036f91908d57888f3d8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>7C636547451960499643&sdata=srgB4g25gGyTHTw4CTBGloaYISc7TngykapuNBObECY%3D&
>reserved=0>
>Virus-free.
>https://na01.safelinks.protection.outlook.com/?url=www.avast.com&data=02%7
>C01%7Caharui%40adobe.com%7C00be1125ff064036f91908d57888f3d8%7Cfa7b1b5a7b34
>438794aed2c178decee1%7C0%7C0%7C636547451960499643&sdata=2lJGLP%2FTb6jmmuot
>pAciekV%2BV6R50G3XTYDq%2BctZMKQ%3D&reserved=0
><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.avas
>t.com%2Fsig-email%3Futm_medium%3Demail%26utm_source%3Dlink%26utm_campaign%
>3Dsig-email%26utm_content%3Dwebmail&data=02%7C01%7Caharui%40adobe.com%7C00
>be1125ff064036f91908d57888f3d8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>7C636547451960499643&sdata=srgB4g25gGyTHTw4CTBGloaYISc7TngykapuNBObECY%3D&
>reserved=0>
><#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
>On Tue, Feb 20, 2018 at 1:26 PM, Alex Harui <ah...@adobe.com.invalid>
>wrote:
>
>> Hi,
>>
>> I just pushed compiler changes that will default to reporting a new
>> warning if you have public var in your Royale code. Public methods,
>> getters and setters are fine, but public vars do not handle
>>minification.
>>
>> I also just pushed a sweep of the framework code to eliminate public var
>> usage or add a directive to suppress the warning. At some point in
>>time I
>> will probably sweep the examples, but I'm letting it spit a few warnings
>> for now. I hope to remove the * selector this week and that will
>>require
>> another sweep of the examples.
>>
>> Not using public vars should increase the changes that your minified
>>code
>> will run. I put some information about public var usage in the wiki.
>>I'm
>> not sure if or where it should go in the user doc. Users may be able
>> survive with more public vars since it mainly matters for vars used in
>> MXML, Binding, and States. But we want the framework to be clean, so if
>> you see a warning from your framework code, please clean it up.
>>
>>
>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c
>>om%2Fapache%2Froyale-asjs%2Fwiki%2FPublic-Variables&data=02%7C01%7Caharui
>>%40adobe.com%7C00be1125ff064036f91908d57888f3d8%7Cfa7b1b5a7b34438794aed2c
>>178decee1%7C0%7C0%7C636547451960499643&sdata=NsEnVpwiOc9bR6TSbwJ%2FKmJLLs
>>WvhMRN83uLj0JuK3A%3D&reserved=0
>>
>> Thanks,
>> -Alex
>>
>>
>
>
>--
>Andrew Wetmore
>
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcottage14.
>blogspot.com%2F&data=02%7C01%7Caharui%40adobe.com%7C00be1125ff064036f91908
>d57888f3d8%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636547451960499643
>&sdata=7tfthDnaui6tpk0JIbAi3%2BN3JTELdLw%2Bgjo7Rf0o%2Fts%3D&reserved=0
Re: Public Vars
Posted by Andrew Wetmore <co...@gmail.com>.
Am I right that public vars were no problem in apps compiled for Flash or
AIR use, and that this improvement relates to creating a Royale app for JS
production?
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
On Tue, Feb 20, 2018 at 1:26 PM, Alex Harui <ah...@adobe.com.invalid>
wrote:
> Hi,
>
> I just pushed compiler changes that will default to reporting a new
> warning if you have public var in your Royale code. Public methods,
> getters and setters are fine, but public vars do not handle minification.
>
> I also just pushed a sweep of the framework code to eliminate public var
> usage or add a directive to suppress the warning. At some point in time I
> will probably sweep the examples, but I'm letting it spit a few warnings
> for now. I hope to remove the * selector this week and that will require
> another sweep of the examples.
>
> Not using public vars should increase the changes that your minified code
> will run. I put some information about public var usage in the wiki. I'm
> not sure if or where it should go in the user doc. Users may be able
> survive with more public vars since it mainly matters for vars used in
> MXML, Binding, and States. But we want the framework to be clean, so if
> you see a warning from your framework code, please clean it up.
>
> https://github.com/apache/royale-asjs/wiki/Public-Variables
>
> Thanks,
> -Alex
>
>
--
Andrew Wetmore
http://cottage14.blogspot.com/