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: labri...@digitalprimates.net
> To: flex-dev@incubator.apache.org
> 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
>
