I'll look into it. Get Outlook for Android<https://aka.ms/ghei36>
________________________________ From: Piotr Zarzycki <[email protected]> Sent: Tuesday, February 20, 2018 12:50:12 PM To: [email protected] 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 <[email protected]>: > 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" <[email protected]> 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 <[email protected]> > >>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" <[email protected] > >><mailto:[email protected]>> 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 <[email protected]> > >>>> 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" <[email protected] > >>>> <mailto:[email protected] <mailto:[email protected]>>> 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 <[email protected] > >>>>>><mailto:[email protected]>> > >>>>>> 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>*
