Re: [1/4] git commit: add removeItem to IList and ListCollectionView
Ok, as many people as stated they will prefer not revert, I will not make
any changes and will keep the IList removeItem new method and the method
implementations. I will postpone a Discussion thread for a later time when
we have more use cases that will make us to talk and discuss about global
philosophy.
Thanks all.
Carlos
2013/3/25 Cosma Colanicchia
> +1 on adding the method to IList... I have *lot* of code that look like
>
> var index:int = list.getItemIndex(object);
> if (index >= 0) {
> list.removeItemAt(index);
> }
>
> I think this is ugly and verbose, and it pollutes my function namespace - I
> ends up with "indexOfItemToRemove1" and some like this, as AS3 lacks
> java-like block-level variables. Having static helper functions to mitigate
> this kind of micro-issues is not ideal, as it makes the code less readable
> and fluent, at least for my eyes.
>
> I also think it is actually correct that existing methods are broken on
> first compile: its a nice way for owners of that code to be aware of the
> change, and thus look up if their custom method implementation can be
> trashed or must be kept and renamed for some reason.
>
>
>
>
>
> 2013/3/25 Alex Harui
>
> >
> >
> >
> > On 3/25/13 8:00 AM, "Carlos Rovira"
> wrote:
> >
> > > So Alex,
> > >
> > > what we do? revert? let the change live? make a Discuss thread so
> people
> > > could express the phylosophy with this issue and future similar
> tickets?
> > >
> > > Please, let us know so we can act accordingly
> > >
> > It is up to you. I have stated my concerns. There is no right or wrong
> > answer. If you are willing to take the time to start a discuss or poll,
> > feel free. So far, four people have voiced opinions and nobody thinks
> you
> > must revert.
> >
> > --
> > 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
Re: [1/4] git commit: add removeItem to IList and ListCollectionView
+1 on adding the method to IList... I have *lot* of code that look like
var index:int = list.getItemIndex(object);
if (index >= 0) {
list.removeItemAt(index);
}
I think this is ugly and verbose, and it pollutes my function namespace - I
ends up with "indexOfItemToRemove1" and some like this, as AS3 lacks
java-like block-level variables. Having static helper functions to mitigate
this kind of micro-issues is not ideal, as it makes the code less readable
and fluent, at least for my eyes.
I also think it is actually correct that existing methods are broken on
first compile: its a nice way for owners of that code to be aware of the
change, and thus look up if their custom method implementation can be
trashed or must be kept and renamed for some reason.
2013/3/25 Alex Harui
>
>
>
> On 3/25/13 8:00 AM, "Carlos Rovira" wrote:
>
> > So Alex,
> >
> > what we do? revert? let the change live? make a Discuss thread so people
> > could express the phylosophy with this issue and future similar tickets?
> >
> > Please, let us know so we can act accordingly
> >
> It is up to you. I have stated my concerns. There is no right or wrong
> answer. If you are willing to take the time to start a discuss or poll,
> feel free. So far, four people have voiced opinions and nobody thinks you
> must revert.
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>
Re: [1/4] git commit: add removeItem to IList and ListCollectionView
On 3/25/13 8:00 AM, "Carlos Rovira" wrote: > So Alex, > > what we do? revert? let the change live? make a Discuss thread so people > could express the phylosophy with this issue and future similar tickets? > > Please, let us know so we can act accordingly > It is up to you. I have stated my concerns. There is no right or wrong answer. If you are willing to take the time to start a discuss or poll, feel free. So far, four people have voiced opinions and nobody thinks you must revert. -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
Re: [1/4] git commit: add removeItem to IList and ListCollectionView
So Alex, what we do? revert? let the change live? make a Discuss thread so people could express the phylosophy with this issue and future similar tickets? Please, let us know so we can act accordingly Best Carlos 2013/3/25 Alex Harui > > > > On 3/25/13 3:02 AM, "Harbs" wrote: > > > I really don't see this as a really big deal. > > > > Even if someone implemented ILIst. The first time they try to compile, > they > > will see a compile error that they didn't implement the new methods. All > you > > really need to do is add a blank function. > > > > Are we worried about compiled libraries that the user does not have to > source > > to? Is that a real concern? > I've been told that some large companies have lots of legacy code they > don't > like to touch. That's why we did the Marshall Plan. Also, I am concerned > that there are third-party libraries out there without anyone maintaining > them (Parsley for example). > > I don't have any more final word than anyone else, I just want to make sure > we think this is the right move. Breaking custom spark skins was one thing > because there were fewer existing projects depending on it and those > projects would be recent, but Ilist has been around for a long time. > > -- > 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
Re: [1/4] git commit: add removeItem to IList and ListCollectionView
On 3/25/13 3:02 AM, "Harbs" wrote: > I really don't see this as a really big deal. > > Even if someone implemented ILIst. The first time they try to compile, they > will see a compile error that they didn't implement the new methods. All you > really need to do is add a blank function. > > Are we worried about compiled libraries that the user does not have to source > to? Is that a real concern? I've been told that some large companies have lots of legacy code they don't like to touch. That's why we did the Marshall Plan. Also, I am concerned that there are third-party libraries out there without anyone maintaining them (Parsley for example). I don't have any more final word than anyone else, I just want to make sure we think this is the right move. Breaking custom spark skins was one thing because there were fewer existing projects depending on it and those projects would be recent, but Ilist has been around for a long time. -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
Re: [1/4] git commit: add removeItem to IList and ListCollectionView
I really don't see this as a really big deal.
Even if someone implemented ILIst. The first time they try to compile, they
will see a compile error that they didn't implement the new methods. All you
really need to do is add a blank function.
Are we worried about compiled libraries that the user does not have to source
to? Is that a real concern?
On Mar 25, 2013, at 5:18 AM, Alex Harui wrote:
> Carlos,
>
> Did you consider that this change will break all third-party IList
> implementations?
>
> I would prefer that you revert this change and create an IList2 interface.
>
> Sorry,
> -Alex
>
> On 3/24/13 4:06 PM, "carlosrov...@apache.org"
> wrote:
>
>> Updated Branches:
>> refs/heads/develop 251c9b717 -> 5f87fec9e
>>
>>
>> add removeItem to IList and ListCollectionView
>>
>>
>> Project: http://git-wip-us.apache.org/repos/asf/flex-sdk/repo
>> Commit: http://git-wip-us.apache.org/repos/asf/flex-sdk/commit/14e10d49
>> Tree: http://git-wip-us.apache.org/repos/asf/flex-sdk/tree/14e10d49
>> Diff: http://git-wip-us.apache.org/repos/asf/flex-sdk/diff/14e10d49
>>
>> Branch: refs/heads/develop
>> Commit: 14e10d49b65760eb2be9d89e464b21d2483145a8
>> Parents: 251c9b7
>> Author: Carlos Rovira
>> Authored: Sun Mar 24 20:12:05 2013 +0100
>> Committer: Carlos Rovira
>> Committed: Sun Mar 24 20:12:05 2013 +0100
>>
>> --
>> .../projects/framework/src/mx/collections/IList.as | 16 +++-
>> .../src/mx/collections/ListCollectionView.as | 20 +-
>> 2 files changed, 33 insertions(+), 3 deletions(-)
>> --
>>
>>
>> http://git-wip-us.apache.org/repos/asf/flex-sdk/blob/14e10d49/frameworks/proje
>> cts/framework/src/mx/collections/IList.as
>> --
>> diff --git a/frameworks/projects/framework/src/mx/collections/IList.as
>> b/frameworks/projects/framework/src/mx/collections/IList.as
>> index fb91742..e636a7d 100644
>> --- a/frameworks/projects/framework/src/mx/collections/IList.as
>> +++ b/frameworks/projects/framework/src/mx/collections/IList.as
>> @@ -212,7 +212,21 @@ public interface IList extends IEventDispatcher
>> * @productversion Flex 3
>> */
>> function removeAll():void;
>> -
>> +
>> + /**
>> + * Removes the specified item from this list, should it exist.
>> + * Relies on ArrayList implementation
>> + *
>> + * @param item Object reference to the item that should be removed.
>> + * @return Boolean indicating if the item was removed.
>> + *
>> + * @langversion 3.0
>> + * @playerversion Flash 9
>> + * @playerversion AIR 1.1
>> + * @productversion Apache Flex 4.10
>> + */
>> + function removeItem( item:Object ):Boolean;
>> +
>> /**
>> * Removes the item at the specified index and returns it.
>> * Any items that were after this index are now one index earlier.
>>
>> http://git-wip-us.apache.org/repos/asf/flex-sdk/blob/14e10d49/frameworks/proje
>> cts/framework/src/mx/collections/ListCollectionView.as
>> --
>> diff --git
>> a/frameworks/projects/framework/src/mx/collections/ListCollectionView.as
>> b/frameworks/projects/framework/src/mx/collections/ListCollectionView.as
>> index af33268..afce033 100644
>> --- a/frameworks/projects/framework/src/mx/collections/ListCollectionView.as
>> +++ b/frameworks/projects/framework/src/mx/collections/ListCollectionView.as
>> @@ -757,8 +757,24 @@ public class ListCollectionView extends Proxy
>> //turns out that there are no neighbors of item in the filtered
>> //list, so item is the 1st item
>> return 0;
>> -}
>> -
>> +}
>> +
>> +/**
>> + * Removes the specified item from this list, should it exist.
>> + * Relies on ArrayList implementation
>> + *
>> + * @param item Object reference to the item that should be removed.
>> + * @return Boolean indicating if the item was removed.
>> + *
>> + * @langversion 3.0
>> + * @playerversion Flash 9
>> + * @playerversion AIR 1.1
>> + * @productversion Apache Flex 4.10
>> + */
>> + public function removeItem( item:Object ):Boolean
>> + {
>> + return list.removeItem( item );
>> + }
>>
>> /**
>> * @inheritDoc
>>
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
Re: [1/4] git commit: add removeItem to IList and ListCollectionView
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 > 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 > 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 > > > >> > >> > >> > >> On 3/24/13 10:22 PM, "Alex Harui" wrote: > >> > >>> > >>> > >>> > >>> On 3/24/13 9:42 PM, "Justin Mclean" 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.9% 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 fir
Re: [1/4] git commit: add removeItem to IList and ListCollectionView
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 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 > >> >> >> >> On 3/24/13 10:22 PM, "Alex Harui" wrote: >> >>> >>> >>> >>> On 3/24/13 9:42 PM, "Justin Mclean" 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.9% 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
Re: [1/4] git commit: add removeItem to IList and ListCollectionView
Hi, I think in this case there's not going to be a lot of 3rd party code effected and it's easy enough to implement if someone want to use Apache Flex. If anyone has another opinion please speak up. > 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 I'd learn towards option 2 or 3 or perhaps 4 or 5 but don't really have a strong opinion. I don't think we should revert. The performance is a non issue IMO - premature optimisation and all that. O(N) is fast unless N is very large and in some cases you wont know the index to remove so it's a useful addition. > In the end it was marked as "easy fix". That was me (I think) as I considered it something easy to do - just trying to encourage people :-) Thanks, Justin
Re: [1/4] git commit: add removeItem to IList and ListCollectionView
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 > > > > On 3/24/13 10:22 PM, "Alex Harui" wrote: > > > > > > > > > On 3/24/13 9:42 PM, "Justin Mclean" 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.9% 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
Re: [1/4] git commit: add removeItem to IList and ListCollectionView
On 3/24/13 10:22 PM, "Alex Harui" wrote: > > > > On 3/24/13 9:42 PM, "Justin Mclean" 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.9% 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
Re: [1/4] git commit: add removeItem to IList and ListCollectionView
On 3/24/13 9:42 PM, "Justin Mclean" 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? 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
Re: [1/4] git commit: add removeItem to IList and ListCollectionView
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? Justin
Re: [1/4] git commit: add removeItem to IList and ListCollectionView
On 3/24/13 9:20 PM, "Justin Mclean" wrote: > Hi, > >> Did you consider that this change will break all third-party IList >> implementations? > Just wondering how common that would be? Over the years I used it quit often > but can't recall needing to implement it. The AS3 commons collections use > there own (different) IList interface. Dunno, but that's why I didn't actually veto. But I would not want to cause someone who did implement it to not migrate to Apache Flex because of it. > >> I would prefer that you revert this change and create an IList2 interface. > > That seems ugly. How about putting the interface in the Apache namespace and > having the classes in question implement both IList interfaces? That way it's > backwards compatible and new code can use if if need be. > If you call it org.apache.flex.collections.IList, you might have to fully qualify IList in other places in the code. I don't really care what we call it or what package it goes in. Could call it IListWithRemoveItem. Carlos will find out if he tries to do what you suggest because he'll find himself fixing a bunch of files again or not. The fact he had to change all of those SDK files was a first clue that this could impact third-parties. -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
Re: [1/4] git commit: add removeItem to IList and ListCollectionView
Hi, > Did you consider that this change will break all third-party IList > implementations? Just wondering how common that would be? Over the years I used it quit often but can't recall needing to implement it. The AS3 commons collections use there own (different) IList interface. > I would prefer that you revert this change and create an IList2 interface. That seems ugly. How about putting the interface in the Apache namespace and having the classes in question implement both IList interfaces? That way it's backwards compatible and new code can use if if need be. Justin
Re: [1/4] git commit: add removeItem to IList and ListCollectionView
Carlos,
Did you consider that this change will break all third-party IList
implementations?
I would prefer that you revert this change and create an IList2 interface.
Sorry,
-Alex
On 3/24/13 4:06 PM, "carlosrov...@apache.org"
wrote:
> Updated Branches:
> refs/heads/develop 251c9b717 -> 5f87fec9e
>
>
> add removeItem to IList and ListCollectionView
>
>
> Project: http://git-wip-us.apache.org/repos/asf/flex-sdk/repo
> Commit: http://git-wip-us.apache.org/repos/asf/flex-sdk/commit/14e10d49
> Tree: http://git-wip-us.apache.org/repos/asf/flex-sdk/tree/14e10d49
> Diff: http://git-wip-us.apache.org/repos/asf/flex-sdk/diff/14e10d49
>
> Branch: refs/heads/develop
> Commit: 14e10d49b65760eb2be9d89e464b21d2483145a8
> Parents: 251c9b7
> Author: Carlos Rovira
> Authored: Sun Mar 24 20:12:05 2013 +0100
> Committer: Carlos Rovira
> Committed: Sun Mar 24 20:12:05 2013 +0100
>
> --
> .../projects/framework/src/mx/collections/IList.as | 16 +++-
> .../src/mx/collections/ListCollectionView.as | 20 +-
> 2 files changed, 33 insertions(+), 3 deletions(-)
> --
>
>
> http://git-wip-us.apache.org/repos/asf/flex-sdk/blob/14e10d49/frameworks/proje
> cts/framework/src/mx/collections/IList.as
> --
> diff --git a/frameworks/projects/framework/src/mx/collections/IList.as
> b/frameworks/projects/framework/src/mx/collections/IList.as
> index fb91742..e636a7d 100644
> --- a/frameworks/projects/framework/src/mx/collections/IList.as
> +++ b/frameworks/projects/framework/src/mx/collections/IList.as
> @@ -212,7 +212,21 @@ public interface IList extends IEventDispatcher
> * @productversion Flex 3
> */
> function removeAll():void;
> -
> +
> + /**
> + * Removes the specified item from this list, should it exist.
> + * Relies on ArrayList implementation
> + *
> + * @param item Object reference to the item that should be removed.
> + * @return Boolean indicating if the item was removed.
> + *
> + * @langversion 3.0
> + * @playerversion Flash 9
> + * @playerversion AIR 1.1
> + * @productversion Apache Flex 4.10
> + */
> + function removeItem( item:Object ):Boolean;
> +
> /**
> * Removes the item at the specified index and returns it.
> * Any items that were after this index are now one index earlier.
>
> http://git-wip-us.apache.org/repos/asf/flex-sdk/blob/14e10d49/frameworks/proje
> cts/framework/src/mx/collections/ListCollectionView.as
> --
> diff --git
> a/frameworks/projects/framework/src/mx/collections/ListCollectionView.as
> b/frameworks/projects/framework/src/mx/collections/ListCollectionView.as
> index af33268..afce033 100644
> --- a/frameworks/projects/framework/src/mx/collections/ListCollectionView.as
> +++ b/frameworks/projects/framework/src/mx/collections/ListCollectionView.as
> @@ -757,8 +757,24 @@ public class ListCollectionView extends Proxy
> //turns out that there are no neighbors of item in the filtered
> //list, so item is the 1st item
> return 0;
> -}
> -
> +}
> +
> +/**
> + * Removes the specified item from this list, should it exist.
> + * Relies on ArrayList implementation
> + *
> + * @param item Object reference to the item that should be removed.
> + * @return Boolean indicating if the item was removed.
> + *
> + * @langversion 3.0
> + * @playerversion Flash 9
> + * @playerversion AIR 1.1
> + * @productversion Apache Flex 4.10
> + */
> + public function removeItem( item:Object ):Boolean
> + {
> + return list.removeItem( item );
> + }
>
> /**
> * @inheritDoc
>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
