Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: flex-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: local policy)
From: "Michael A. Labriola" <labriola@digitalprimates.net>
To: "flex-dev@incubator.apache.org" <flex-dev@incubator.apache.org>
Subject: RE: ArrayList itemUpdateHandler Change
Thread-Topic: ArrayList itemUpdateHandler Change
Thread-Index: Ac0XJIdorBRgj3C0S3SvVKmFYVqazAACp1HfAAAYAvAAAD7EkAALdFoAAApmxjA=
Date: Tue, 10 Apr 2012 16:18:43 +0000
Message-ID: 
 <EB6F7A48D477254EAB8F675582F80CD72673786C@DPSBS1.digitalprimates.local>
References: 
 <EB6F7A48D477254EAB8F675582F80CD726737610@DPSBS1.digitalprimates.local>,<CBA9A09F.3EE52%aharui@adobe.com>,<EB6F7A48D477254EAB8F675582F80CD72673778A@DPSBS1.digitalprimates.local>,<EB6F7A48D477254EAB8F675582F80CD7267377A7@DPSBS1.digitalprimates.local>
 <SNT110-W25B1AD0A45C446033583A6E1340@phx.gbl>
In-Reply-To: <SNT110-W25B1AD0A45C446033583A6E1340@phx.gbl>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

>I agree with this, there are a number of inconsistencies in the handling o=
f indexes throughout the framework.  I think that it is a worthwhile effort=
 to address them in this way.  As Mike states, the number of side >effects =
could be numerous.  But with that being said, I think that changing this fr=
om unsigned to signed may be the first step in identifying some of these si=
de effects and possibly fix one or two incidental issues.  As a >long time =
flex developer, I would add a word of caution that this seems like a slippe=
ry slope.  Once we go down this path we may find a huge number of subsequen=
t changes flying around.  I think we will definitely >resolve some long pen=
ding issues, but we should be very careful and aware that this could be a r=
ather deep rabbit hole.

I agree. I have identified about 20 inconsistencies so far in the way prope=
rty change is dispatched or used in certain circumstances and I think the f=
ixes will be great. Again though, I am not proposing any of these until we =
have tests. If you look at the unit tests I wrote for ArrayList, you will s=
ee things like "This demonstrates the way it works today, but are we sure w=
e want this behavior," because I do think there are actually a number of is=
sues that should be addressed.

For example, using setItemAt, the CollectionChange event has a PropertyChan=
geEvent for its items, and those items have oldValue, newValue and property=
, which is actually the index. However, in the case of an add or remove, th=
e items array actually contains the real item that was added or removed, no=
t a PropertyChangeEvent. In this case of an update, the property change com=
es first and the collection change second. In the case of an add or remove,=
 it is the opposite.

Mike