I agree with your solution Carlos, I think that the fix should be in the IList itself, and not need create an alternative version.
BTW, if it breaks the implementation of third parties will be a minor problem, and if you want to make an interface for compatibility, and call it IList2 as Alex said, it should be that did not contain the correction, so the people can implement this interface (to extinguish) or implement the new method. Best, -- Jose Barragan Chief Software Architect josebarra...@apache.org On Mar 25, 2013, at 9:01 AM, Carlos Rovira <carlos.rov...@codeoscopic.com> wrote: > Hi Alex and Justin, > > when I came to the problem that I was to change 12 implementations I > thought about it, but taking into account how other os products perform > (Spring, Hibernate,...) over versions I thought that this kins of changes > was possible since people should have a similar implementation and will be > removing his method or overriding and extending. Other point was that we > would expect few cases like this since in real apps people end making a > removeItemAt(getItemIndex) thing at use case level, repeating code over and > over. > > As I said if you try to upgrade from java os libraries like Hibernate, you > will find you must to leverage a several change in your product that many > times are not possible without invest many hours to finish the change, and > people behind that product ends doing it due to always look forward. > > In this case, the change is not so big and we should expect not too much > people having to make changes, but we could take this one to decide what > philoshophy adopt in this cases. > > > Options are: > > 1.- make a revert of all branch > 2.- make a new Interface that extends the IList in the apache namespace > with this method and make the 12 classes implement this new interface > instead the old one. > 3.- remove the new method from IList interface and left the new methods in > the 12 classes. > 4.- Make an utility class > 5.- leave the change as it is > more? > > Alex, you have the last word, but consider what other projects perform > since you'll find that in the months coming some other changes will had to > be crafted that will make some developers to make several changes if they > want to upgrade. We can look forward to minimize this problem but in the > end we must progress. For me additive changes like this should not be a > problem and people should adapt to this one. In the end it was marked as > "easy fix". > > Please, let me know what to do and I will perform the change. > > > > > > > 2013/3/25 Alex Harui <aha...@adobe.com> > >> >> >> >> On 3/24/13 10:22 PM, "Alex Harui" <aha...@adobe.com> wrote: >> >>> >>> >>> >>> On 3/24/13 9:42 PM, "Justin Mclean" <jus...@classsoftware.com> wrote: >>> >>>> Hi, >>>> >>>>> The fact he had to change all of those SDK files was a first clue that >> this >>>>> could impact third-parties. >>>> Another possibility (possibly a little less useful but 100% 3rd party >>>> compatible) is to leave the interface as it was before (perhaps with >> the new >>>> method commented out to indicate it exists) and keep the new methods? >> And actually, your proposal is only 99.99999% 3rd party compatible. There >> is a non-zero probability that someone implemented removeItem on a subclass >> of ListCollectionView or any of the other modified classes and this will >> bust them. >> >>> That's a possibility, or create a utility class that implements that >> method. >>> I doubt there is significant performance gains by implementing it over >> and >>> over again in several places. >>> >>> Really, the documentation for that method should come with a warning >> that it >>> does a linear search and that for large data sets, some other mechanism >>> should be used to remove items. I don't write real applications like you >>> folks do, but I would first make sure that I absolutely needed a method >> like >>> this. For example, if you are deleting an object selected from a List, >> you >>> already have the selectedIndex. Or if you know something about the data >> and >>> its sort order, you can sometimes know to start at the end and work >>> backwards. >> >> -- >> Alex Harui >> Flex SDK Team >> Adobe Systems, Inc. >> http://blogs.adobe.com/aharui >> >> > > > -- > Carlos Rovira > Director de Tecnología > M: +34 607 22 60 05 > F: +34 912 94 80 80 > http://www.codeoscopic.com > http://www.directwriter.es > http://www.avant2.es
