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
On Sat, Jan 14, 2012 at 2:32 PM, Tink f...@tink.ws 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
On 1/15/12 4:19 AM, jude flexcapaci...@gmail.com 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 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 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
On 1/14/12 12:32 PM, Tink f...@tink.ws 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
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 function get x():int
{
return this._105x;
}
public function
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,
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
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
On 1/13/12 4:27 PM, João Fernandes joaopedromartinsfernan...@gmail.com
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
11 matches
Mail list logo
