royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <>
Subject Re: Public Vars
Date Tue, 20 Feb 2018 19:19:15 GMT
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.


On 2/20/18, 11:06 AM, "Gabe Harbs" <> 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?
>> On Feb 20, 2018, at 8:43 PM, Alex Harui <>
>> 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
>> 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
>> component developer know the context when they type "public var".
>> I did consider a flag that would have the JS output automatically
>> a getter/setter for every public var.  But that would significantly
>> 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" <
>><>> 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 <>
>>>> wrote:
>>>> As a said, it mainly matters for MXML, Binding, and States.
>>>> I believe it will matter in accessing modules and a module accessing
>>>> 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
>>>> 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
>>>> you then create a new instance of a Value Object and set its
>>>> 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
>>>> things that needed to be changed.  I might have suppressed some
>>>> 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" <
>>>> < <>>>
>>>>> I have over 700 public vars in my app and it handles minification
>>>>> 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 <
>>>>>> 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
>>>>>> 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
>>>>>> I'm
>>>>>> not sure if or where it should go in the user doc.  Users may be
>>>>>> survive with more public vars since it mainly matters for vars used
>>>>>> MXML, Binding, and States.  But we want the framework to be clean,
>>>>>> if
>>>>>> you see a warning from your framework code, please clean it up.
>>>>>> .c 
>>>>>> b.c>
>>>>>> ui
>>>>>> 93e6c53f985c4a6ae7d408d5788cd84a%7Cfa7b1b5a7b34438794aed2c
>>>>>> 3a
>>>>>> LNONqTmEGghTUf0%3D&reserved=0
>>>>>> Thanks,
>>>>>> -Alex

View raw message