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 2012/02/20 19:52:38 UTC

Falcon and MXML (was Re: Adobe / Apache / Spoon Flex Tour)



On 2/20/12 4:30 AM, "olegsivokon@gmail.com" <ol...@gmail.com> wrote:

> Alex, then I have several more questions regarding the framework and
> compiler integration. Previously, no one cared to separate these two
> things, which resulted in that certain features of MXML weren't available
> to non-framework code.
And now we care.
> 
> I am seriously worried about the new compiler when you say that things like
> MXML are going to be built-in. Having long history of Adobe providing low
> quality AS3 code, I would not like any code generation to be built into
> compiler, or, at least, not in the way it cannot be _entirely_ altered.
The plan is to donate Falcon to Apache and then we can entirely alter any
generated code.  But the plan for MXML handling in Falcon was to generate
more data and less code so you can interpret the data in the framework any
way you want and not have to muck with the compiler.

My understanding of the state of Falcon and MXML is that Gordon and folks
wrote enough code to mimic the same one-method-per-tag code gen and compile
some basic apps.  I don't think we want the codegen, but the parsing logic
down to the point where it generates code should be useful.

What I implemented/prototyped was new encoded-data codegen and the requisite
changes in the framework to interpret the data.  It worked on some test apps
I used to test the codegen, but then the big announcement happened and life
hasn't been the same since.

I found working in Falcon to be much easier than MXMLC so altering its
behavior should be much more straightforward.

-- 
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui