incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael A. Labriola" <labri...@digitalprimates.net>
Subject RE: ArrayList itemUpdateHandler Change
Date Tue, 10 Apr 2012 16:18:43 GMT
>I agree with this, there are a number of inconsistencies in the handling of 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 from unsigned to signed may be the first step in identifying some of these
side 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 slippery slope.  Once we go down this
path we may find a huge number of subsequent changes flying around.  I think we will definitely
>resolve some long pending issues, but we should be very careful and aware that this could
be a rather deep rabbit hole.

I agree. I have identified about 20 inconsistencies so far in the way property change is dispatched
or used in certain circumstances and I think the fixes 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 see things like "This demonstrates the way it works today, but are we sure we want
this behavior," because I do think there are actually a number of issues that should be addressed.

For example, using setItemAt, the CollectionChange event has a PropertyChangeEvent 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, the items array actually contains the real item
that was added or removed, not a PropertyChangeEvent. In this case of an update, the property
change comes first and the collection change second. In the case of an add or remove, it is
the opposite.

Mike


Mime
View raw message