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

Reply via email to