On 11/16/12 1:52 PM, "Fréderic Cox" <coxfrede...@gmail.com> wrote:
> I'm glad Alex is here because I believe he does not only have
> the experience but also great ideas where Flex should be headed. And he
> might have been blocked previously by business decisions but now can take
> Flex to a even higher level.
>
Keep in mind that I'm the biggest proponent of the full re-write. We may
still find a few performance mistakes in the current code (like the Chart
styles init that just got fixed), but really, some very smart people have
spent a lot of time on the current code and haven't found any easy wins.
IMO, the framework is slow because lots of code is running just in case.
This is especially true for mobile apps where you have the most constrained
runtime environment. The issue that came in today on the users list about
slow List performance I'm sure is in part due to TextLine being a bit
slower, but probably more due to lots of other code running as well.
Plus, as many have recently said, the intertwined code we currently have
makes it hard for the volunteer to be successful in their spare time.
I tried the big refactor and it was too difficult for me, but one of the
main difficulties was the fact that there was lots of other development
going on in the trunk at the same time and keeping my branch running was
nearly impossible. It could be that there won't be as much active
development in Apache Flex and a refactor branch will be manageable, but the
other problem you run into is that every line of code is needed for some
reason at some point, and you tend to start leaving code in.
Starting over definitely has its risks, but I think it will have the best
outcome. It won't make 100% parity ever and I'd shoot for 80% over two or
three years. But it will be designed to port to other platforms, and be
modular so the volunteer has a chance of making a difference.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
