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?
--
João Fernandes
