flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tink <f...@tink.ws >
Subject Re: Compiler optimization for getter/setter
Date Sat, 14 Jan 2012 20:32:54 GMT
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 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.

I can't comment on Alex's suggestions for the future, but I don't  
think thats what happens in the current SDK?

If you create a getter/setter it only dispatches the  
PropertyChangeEvent if you have marked it as being [Bindable], or if  
you have marked the class as being [Bindable]. Omit these and it will  
never dispatch a PropertyChangeEvent.

You can also very easy override this default binding functionality by  
specifying a custom event in your  
[Bindable(event="myCustomEventType")]. This means it is then up to you  
to dispatch the event and it isolates this property from being mixed  
in with other properties as they can all dispatch different events.  
This is also more explicit as you can look in the code and see the  
event you should listen for, iwhich if your adding the event listener  
yourself is very useful (you should also use the [Event] metadata to  
specify all the events that you class will dispatch for code hinting).

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 interested in, the  
getter is invoked, if not, nothing happens (i.e. it doesn't force all  
the getters to be re-evaluated).

View raw message