It might be that the compiler is not handling [Bindable] on interfaces.
I'm pretty sure I've seen it work on classes. If you can run a quick test
to prove that, then that should be fixed in the compiler.
But using [Bindable] sets up change events on the public properties in the
class and if the value of the property is effectively a constant, then you
can make your app smaller and faster by telling the subsystem that some
property won't be dispatching change events.
I don't know if defining the properties as "const" instead of "var" would
work or not. Might be worth a try.
Some day in the future, I hope we find time to optimize binding to
constants. And in this case, binding for localization. If your app does
not support changing locales at runtime (it picks up locale at startup and
assumes it never changes), there is probably better code that could be
generated.
Thanks,
-Alex
On 6/20/17, 12:09 AM, "Yishay Weiss" <yishayj...@hotmail.com> wrote:
>I agree it’s wasteful, but there’s a lot of old code that we’re porting
>that uses this as a shortcut. I’ve changed all interface get definitions
>to be prefixed with [Bindable("__NoChangeEvent__")] and the compiler now
>seems happy. It should probably be enough to add it the interface
>declaration instead.
>
>If I were to rewrite the code what syntax would you suggest instead of
><Label text="{locStrings.SEARCH}”/> ?
>
>From: Alex Harui<mailto:aha...@adobe.com.INVALID>
>Sent: Tuesday, June 20, 2017 9:57 AM
>To: dev@flex.apache.org<mailto:dev@flex.apache.org>
>Subject: Re: [FlexJS] How Binding works?
>
>I believe the warning was that the value of PURCHASED could change. The
>Bindable subsystem does not know that the getter will always return the
>same string literal. If other stuff could change, but didn't specify a
>change event, I would hope the compiler would warn about that part of the
>bindable expression.
>
>IMO, one should never use plain [Bindable] with getters and setters. That
>just wraps the getter/setter in another getter/setter with change event
>detection. That adds up eventually both in code size and runtime.
>Suddenly you are making two function calls instead of one to access the
>underlying value.
>
>You could use [Bindable("__NoChangeEvent__")] if you know a value doesn't
>change but isn't a const. You probably don't want to add listeners for
>when PURCHASED changes, just when the current location manager changes.
>
>Of course, I could be wrong.
>
>-Alex
>
>
>
>On 6/19/17, 11:28 PM, "yishayw" <yishayj...@hotmail.com> wrote:
>
>>It looks like changing the definitions of the interface and the class to
>>
>> [Bindable]function get PURCHASED():String;
>>and
>> [Bindable]public function get PURCHASED():String { return
>>"PURCHASED"; }
>>
>>worked.
>>
>>So is it a bug that declaring the class and the interface as bindable was
>>not enough?
>>
>>
>>
>>
>>
>>--
>>View this message in context:
>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fl
>>e
>>x-development.2333347.n4.nabble.com%2FFlexJS-How-Binding-works-tp57096p62
>>4
>>85.html&data=02%7C01%7C%7Cdeee45fa75c74c1828da08d4b7a7f7f2%7Cfa7b1b5a7b34
>>4
>>38794aed2c178decee1%7C0%7C0%7C636335379433525746&sdata=uK6hxHRAC%2BkVi8%2
>>B
>>igjlqgOKAypeFlS1EwLbZ6qNniDk%3D&reserved=0
>>Sent from the Apache Flex Development mailing list archive at Nabble.com.
>
