Hi Jose, as I think on it I'm more convinced that this is the way
To make some parallelism, I remember changes like the added states in TextInputSkin from Flex 4.5 to 4.5.1 (I can't ensure the version) to support new prompt skin part. We get "disabledStates" (normalWithPrompts and disabledWithPrompt) and make all of us to rewrite our skins. A change that maybe was more aggressive, but was hide in the new minor version. This one is less aggressive since I'm sure that people making it's own IList implementation should be very few, against people using new "removeItem" that will be considerably bigger number. If people implementing must implement this method or should override and call parent, or replace for his own implementation, it's fine with me. As I state this is more about future phylosophy to adopt in forthcoming changes so maybe we should make a [Discuss] Thread? Again, I will make the needed changes although for me option 5 is the option. 2013/3/25 Jose Barragan <jose.barra...@codeoscopic.com> > 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 > > -- 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
