incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Coleman <>
Subject RE: ArrayList itemUpdateHandler Change
Date Tue, 10 Apr 2012 16:42:04 GMT

That is exactly my point.  We can "fix" a whole slew of big, bad, annoying things.  but we
will end up creating an SDK version that will totally shatter many existing applications which
most likely will have implemented careful workarounds and quirk-specific code for quirks that
we will be "resolving"...  Don't get me wrong, this is a great idea and well worth the time
in my opinion, but how will we prepare  (or better, shield) the community from the effects
on the common developer's code?

> From:
> To:
> Subject: RE: ArrayList itemUpdateHandler Change
> Date: Tue, 10 Apr 2012 16:18:43 +0000
> >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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message