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
phi
+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
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 m
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 reall
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.
>
> A
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
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 disabledWithPro
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 sa
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 ILi
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
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
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 (pe
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
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 u
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 pre
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 -> 5f87
16 matches
Mail list logo
