incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Coleman <david_coleman_...@hotmail.com>
Subject RE: ArrayList itemUpdateHandler Change
Date Tue, 10 Apr 2012 16:10:12 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.

> From: labriola@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
> 
 		 	   		  
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message