incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: Compiler optimization for getter/setter
Date Fri, 13 Jan 2012 21:49:00 GMT
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, then you can
further optimize by swapping in a model that only dispatches the
notifications you know you need.


On 1/13/12 2:28 AM, "João Fernandes" <joaopedromartinsfernandes@gmail.com>
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 function get x():int
> {
> return this._105x;
> }
> 
> public function set x(value:int):void
> {
> var oldValue:Object=this._105x;
> if (oldValue !== value)
>  {
> this._105x=value;
> if (this.hasEventListener("propertyChange"))
>  this.dispatchEvent(mx.events.PropertyChangeEvent.createUpdateEvent(this,
> "x", oldValue, value));
> }
> }
> 
> the problem with this approach is that each time 1 property in that class
> is changed and dispatches the propertyChangeEvent which forces all getters
> to be re-evaluated.
> 
> What I'm proposing is that the compiler generates like this
> 
> [Bindable(event="xChange")]
> public function get x():int
> {
> return this._105x;
> }
> 
> public function set x(value:int):void
> {
> var oldValue:Object=this._105x;
> if (oldValue !== value)
>  {
> this._105x=value;
> if (this.hasEventListener("xChange"))
>  this.dispatchEvent(new Event("xChange"));
> if (this.hasEventListener("propertyChange"))
>  this.dispatchEvent(mx.events.PropertyChangeEvent.createUpdateEvent(this,
> "x", oldValue, value));
> }
> }
> 
> dispatching the 2 events, the first will allow the x getter to be called
> without requiring all possible getters to be triggered and the
> propertyChangeEvent will allow to keep compatibility with all the
> collections that depend on that event to notify that a property on a value
> object has changed.
> 
> I'm not sure if dispatching a second event will be "heavy" but considering
> a large number of bindable properties that some classes can have,
> evaluating all the getters might be way heavier.
> 
> Does this seem a candidate for a patch in the compiler or does anyone see
> any drawback from this approach that I'm not considering?

-- 
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui


Mime
View raw message