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 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" <joaopedromartinsfernan...@gmail.com > (mailto:joaopedromartinsfernan...@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 > >
