You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Alex Harui <ah...@adobe.com> on 2013/03/25 04:18:42 UTC
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, "carlosrovira@apache.org" <ca...@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 <ca...@gmail.com>
> Authored: Sun Mar 24 20:12:05 2013 +0100
> Committer: Carlos Rovira <ca...@gmail.com>
> 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
Posted by Carlos Rovira <ca...@codeoscopic.com>.
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 <jo...@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
> josebarragan@apache.org
>
> On Mar 25, 2013, at 9:01 AM, Carlos Rovira <ca...@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 <ah...@adobe.com>
> >
> >>
> >>
> >>
> >> On 3/24/13 10:22 PM, "Alex Harui" <ah...@adobe.com> wrote:
> >>
> >>>
> >>>
> >>>
> >>> On 3/24/13 9:42 PM, "Justin Mclean" <ju...@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
Re: [1/4] git commit: add removeItem to IList and ListCollectionView
Posted by Jose Barragan <jo...@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
josebarragan@apache.org
On Mar 25, 2013, at 9:01 AM, Carlos Rovira <ca...@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 <ah...@adobe.com>
>
>>
>>
>>
>> On 3/24/13 10:22 PM, "Alex Harui" <ah...@adobe.com> wrote:
>>
>>>
>>>
>>>
>>> On 3/24/13 9:42 PM, "Justin Mclean" <ju...@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
Re: [1/4] git commit: add removeItem to IList and ListCollectionView
Posted by Justin Mclean <ju...@classsoftware.com>.
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
Posted by Carlos Rovira <ca...@codeoscopic.com>.
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 <ah...@adobe.com>
>
>
>
> On 3/24/13 10:22 PM, "Alex Harui" <ah...@adobe.com> wrote:
>
> >
> >
> >
> > On 3/24/13 9:42 PM, "Justin Mclean" <ju...@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
Re: [1/4] git commit: add removeItem to IList and ListCollectionView
Posted by Alex Harui <ah...@adobe.com>.
On 3/24/13 10:22 PM, "Alex Harui" <ah...@adobe.com> wrote:
>
>
>
> On 3/24/13 9:42 PM, "Justin Mclean" <ju...@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
Re: [1/4] git commit: add removeItem to IList and ListCollectionView
Posted by Alex Harui <ah...@adobe.com>.
On 3/24/13 9:42 PM, "Justin Mclean" <ju...@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?
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
Posted by Justin Mclean <ju...@classsoftware.com>.
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
Posted by Alex Harui <ah...@adobe.com>.
On 3/24/13 9:20 PM, "Justin Mclean" <ju...@classsoftware.com> 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
Posted by Justin Mclean <ju...@classsoftware.com>.
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
Posted by Carlos Rovira <ca...@codeoscopic.com>.
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 <co...@gmail.com>
> +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 <ah...@adobe.com>
>
> >
> >
> >
> > On 3/25/13 8:00 AM, "Carlos Rovira" <ca...@codeoscopic.com>
> 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
Posted by Cosma Colanicchia <co...@gmail.com>.
+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 <ah...@adobe.com>
>
>
>
> On 3/25/13 8:00 AM, "Carlos Rovira" <ca...@codeoscopic.com> 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
Posted by Alex Harui <ah...@adobe.com>.
On 3/25/13 8:00 AM, "Carlos Rovira" <ca...@codeoscopic.com> 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
Posted by Carlos Rovira <ca...@codeoscopic.com>.
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 <ah...@adobe.com>
>
>
>
> On 3/25/13 3:02 AM, "Harbs" <ha...@gmail.com> 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
Posted by Alex Harui <ah...@adobe.com>.
On 3/25/13 3:02 AM, "Harbs" <ha...@gmail.com> 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
Posted by Harbs <ha...@gmail.com>.
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, "carlosrovira@apache.org" <ca...@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 <ca...@gmail.com>
>> Authored: Sun Mar 24 20:12:05 2013 +0100
>> Committer: Carlos Rovira <ca...@gmail.com>
>> 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
>