Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: flex-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of rick.winscot@gmail.com
 designates 209.85.213.47 as permitted sender)
Date: Fri, 13 Jan 2012 17:28:49 -0500
From: Rick Winscot <rick.winscot@gmail.com>
To: flex-dev@incubator.apache.org
Message-ID: <9FBDF63ACC0248BFBB778FBCBBD06C6B@gmail.com>
In-Reply-To: <CB35E6CC.39F87%aharui@adobe.com>
References: <CB35E6CC.39F87%aharui@adobe.com>
Subject: Re: Compiler optimization for getter/setter
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="4f10b021_60602e62_14ddf"

--4f10b021_60602e62_14ddf
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Signals... 100x faster.

-- =20
Rick Winscot


On =46riday, 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.
> =20
> In fact, we may not even want to dispatch events at all in this case an=
d
> have a customized notification mechanism that is way more lightweight.
> =20
> And, even more blue sky, if the data model is substitutable, then you c=
an
> further optimize by swapping in a model that only dispatches the
> notifications you know you need.
> =20
> =20
> On 1/13/12 2:28 AM, =22Jo=C3=A3o =46ernandes=22 <joaopedromartinsfernan=
des=40gmail.com (mailto:joaopedromartinsfernandes=40gmail.com)>
> wrote:
> =20
> > 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 setter=
s
> > =20
> > Currently a public variable x will be generated as:
> > =20
> > =5BBindable(event=3D=22propertyChange=22)=5D
> > public function get x():int
> > =7B
> > return this.=5F105x;
> > =7D
> > =20
> > public function set x(value:int):void
> > =7B
> > var oldValue:Object=3Dthis.=5F105x;
> > if (oldValue =21=3D=3D value)
> > =7B
> > this.=5F105x=3Dvalue;
> > if (this.hasEventListener(=22propertyChange=22))
> > this.dispatchEvent(mx.events.PropertyChangeEvent.createUpdateEvent(th=
is,
> > =22x=22, oldValue, value));
> > =7D
> > =7D
> > =20
> > the problem with this approach is that each time 1 property in that c=
lass
> > is changed and dispatches the propertyChangeEvent which forces all ge=
tters
> > to be re-evaluated.
> > =20
> > What I'm proposing is that the compiler generates like this
> > =20
> > =5BBindable(event=3D=22xChange=22)=5D
> > public function get x():int
> > =7B
> > return this.=5F105x;
> > =7D
> > =20
> > public function set x(value:int):void
> > =7B
> > var oldValue:Object=3Dthis.=5F105x;
> > if (oldValue =21=3D=3D value)
> > =7B
> > this.=5F105x=3Dvalue;
> > if (this.hasEventListener(=22xChange=22))
> > this.dispatchEvent(new Event(=22xChange=22));
> > if (this.hasEventListener(=22propertyChange=22))
> > this.dispatchEvent(mx.events.PropertyChangeEvent.createUpdateEvent(th=
is,
> > =22x=22, oldValue, value));
> > =7D
> > =7D
> > =20
> > dispatching the 2 events, the first will allow the x getter to be cal=
led
> > 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.
> > =20
> > I'm not sure if dispatching a second event will be =22heavy=22 but co=
nsidering
> > a large number of bindable properties that some classes can have,
> > evaluating all the getters might be way heavier.
> > =20
> > 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=3F
> > =20
> =20
> =20
> -- =20
> Alex Harui
> =46lex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
> =20
> =20


--4f10b021_60602e62_14ddf--