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
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
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
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
On 3/25/13 3:02 AM, Harbs harbs.li...@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
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 aha...@adobe.com
On 3/25/13 3:02 AM, Harbs
+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
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
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 carlosrov...@apache.org
wrote:
Updated Branches:
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
On 3/24/13 9:20 PM, Justin Mclean jus...@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
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: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
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
14 matches
Mail list logo
