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