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://www.patreon.com/piotrzarzycki
<https://www.patreon.com/piotrzarzycki>*

Reply via email to