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.
> From: labri...@digitalprimates.net
> To: flex-dev@incubator.apache.org
> Subject: RE: ArrayList itemUpdateHandler Change
> Date: Tue, 10 Apr 2012 15:47:12 +0000
>
> >Frankly, all of the propertyChange stuff and collectionChange stuff is a
> >mess and inconsistent. I want to fix it all, but I am trying to make the
> >narrowest number of changes until we have tests. The other method:
>
> Adding to this for a moment. One of the issues here is that when a child
> object is an event dispatcher and dispatches the event, the ArrayList passes
> along that event. That is use case #1 for itemUpdatedHandler... in this use
> case the target can be used for determining which item it was in the Array.
>
> Use case #2 is that this is called when a property is directly modified
> through things like itemUpdated() or setItemAt(), etc. In those cases, there
> is actually a source propery set instead.
>
> However, in both cases itemUpdateHandler attempts to use the target to find
> the index in the array and hence a property change event. Initially I thought
> we could fix this by just having two handlers, and we can... and should. The
> amusing part is that this particular property of the property change event is
> rarely examined in the framework, it is the mere existence of the event that
> causes a refresh. However, this error does actually have some performance
> impact issue (as well as a few times where you can get out of bounds errors)
> in the AdvancedDataGrid.
>
> So, I would like to truly 100% fix it the right way. Things would be better,
> more efficient and we could actually fix some other bugs. I just cant tell
> all of the side effects so I want to keep it contained until we have tests.
>
> Make more sense?
>
> Mike
>
