>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
