On 15 Jan 2012, at 12:19, jude wrote:
What situation does "...force all the getters to be re-evaluated?"
In the case of bindings which were cited in the first post, you would
have to
1. Make a class [Bindable] or use to [Bindable] tag on multiple
properties without specifying a custom
On 1/15/12 4:19 AM, "jude" wrote:
> What situation does "...force all the getters to be re-evaluated?"
Stopping in the debugger with the object referenced in the context.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
On Sat, Jan 14, 2012 at 2:32 PM, Tink wrote:
> If you don't specify a custom event (which IMO is lazy), it still
> shouldn't run all the getters, as when the PropertyChangeEvent is caught,
> the value of 'event.property' is checked. If the string matches the name of
> the property that the code i
I'm not saying we shouldn't optimize, the point of my response was to
clarify how it currently works,
True, unless the handler is inefficiently written,
we all know that any code that is inefficiently written isn't good.
but even then, the
handler is pounded an awful lot and it would b
On 1/14/12 12:32 PM, "Tink" wrote:
> If you don't specify a custom event (which IMO is lazy), it still
> shouldn't run all the getters, as when the PropertyChangeEvent is
> caught, the value of 'event.property' is checked. If the string
> matches the name of the property that the code it inter
On 13 Jan 2012, at 10:28, João Fernandes wrote:
Hi, I know that the code is not available yet but something that
bugs me
currently in the compiler is what is generated for getters and setters
Currently a public variable x will be generated as:
[Bindable(event="propertyChange")]
public functi
On 1/13/12 4:27 PM, "João Fernandes"
wrote:
> I was trying to check if
> there was a possible better way to get Bindable Properties to be more
> efficient without loosing the capability to notify some collection that
> it somehow changed.
I think we'd also want to change the way collections de
On 1/13/12 4:22 PM, "João Fernandes"
wrote:
> On 1/13/2012 9:49 PM, Alex Harui wrote:
>> And, even more blue sky, if the data model is substitutable, then you can
>> further optimize by swapping in a model that only dispatches the
>> notifications you know you need.
> Another item in your wh
Rick I'm well aware of the existance of Signals (or even TurboSignals)
the problem is it doesn't belong natively in the SDK and currently there
are a lot of current implementations that rely on PropertyChange event
but it forces all your properties to dispatch the same event which...
will eval
On 1/13/2012 9:49 PM, Alex Harui wrote:
And, even more blue sky, if the data model is substitutable, then you can
further optimize by swapping in a model that only dispatches the
notifications you know you need.
Another item in your whiteboard?
João Fernandes
Signals... 100x faster.
--
Rick Winscot
On Friday, January 13, 2012 at 4:49 PM, Alex Harui wrote:
> I don't think I would want to dispatch two events or even think about
> dispatch two events.
>
> In fact, we may not even want to dispatch events at all in this case and
> have a customized n
I don't think I would want to dispatch two events or even think about
dispatch two events.
In fact, we may not even want to dispatch events at all in this case and
have a customized notification mechanism that is way more lightweight.
And, even more blue sky, if the data model is substitutable, t
12 matches
Mail list logo
