incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Winscot <rick.wins...@gmail.com>
Subject Re: Compiler optimization for getter/setter
Date Fri, 13 Jan 2012 22:28:49 GMT
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" <joaopedromartinsfernandes@gmail.com (mailto: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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message