incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Quentin Le Hénaff <>
Subject Re: Petition: Flash Catalyst must survive
Date Tue, 10 Jan 2012 23:43:03 GMT
>The basic idea is that our design goals have changed significantly since
>Flex 3, and we should design a framework for those new goals and sacrifice
>some backward compatibility.  Trying to carry all of our legacy forward is
>probably not going to make it successful.

I totally agree ; I'm a 5-years experienced Flex 3 developper and there are
so many stuffs I want to change in the core components in order to make
them more modular, and not only MVC ;
THE question is : which legacy code will not be supported? do we decide on
the fly or can propose/vote for stuff we know we do not want anymore?

On Wed, Jan 11, 2012 at 12:36 AM, Michael Schmalle <>wrote:

>> On 1/10/12 3:16 PM, "Carlos Rovira" <**>
>> wrote:
>>  Alex, IMO, there was a huge necesity for the new spark component set due
>>> to
>>> multiple problems in MX. God methods with lots of mixed code and without
>>> ante separation of concerns that produces lots of lines of code, very
>>> poorly design that makes very difficult or impossible to extend the code,
>>> etc..
>> I agree that MX had lots of issues.  Could they have been solved
>> incrementally vs building a whole new set?  We know for sure that Adobe
>> was
>> unable to complete the new Spark set over several years.
>> Note that at the same time I'm saying we could have incrementally fixed
>> MX,
>> I am also saying I'm going to start my own new set in my whiteboard space.
>> So I'm not saying that incremental is always the way to go, I was
>> supporting
>> Doug claiming that Spark was largely tied to FC.
> Hearing this from you now it would explain why in the beginning the Spark
> set was small, lightweight and manageable and then all the sudden the
> classes got huge and out of control. I stand corrected that there wasn't an
> agenda building that set.
> To bad, wasted a lot of developers time just trying to make a product that
> is dead now. Not like we as component developers had any choice in the
> matter, now we do.
> Mike

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message