flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: Forking the Falcon compiler for Starling/Feathers MXML generation
Date Tue, 01 Mar 2016 23:07:12 GMT


On 3/1/16, 2:30 PM, "Michael Schmalle" <teotigraphixllc@gmail.com> wrote:

>Hey Om,
>
>This is all purely hypothetical in my head right now so I may be missing
>something as well but the first goal is to use Feathers out right, that
>means hooking into Josh's classes.

I think that's the key.  You can continue to have forks of compilers that
don't require touching existing AS code, or touch and/or wrap the AS code
so we only need one compiler.  I'm hoping to convince folks that the
latter takes less energy from the greater community.

Of course, if someone can come up with a set of compiler options that
allows us to dictate enough aspects of the generated code to abstract
between differences in frameworks that would probably be ok, but IMO it is
more than just addChild/addElement.  In Flex, children are not always
created at certain points in the lifecycle.  There is a concept of
Navigators that have deferred instantiation:  the children are not created
until you navigate to that Tab or Page.  The current Falcon output says
"here are your child descriptors.  You figure out what to do with it".

Another consideration is that unlike the Flex SDK which has MXMLC in the
code base, Falcon is currently its own code base and potentially its own
release cycle, so trying to minimize interdependencies between the
frameworks and compilers seems like a good idea, and almost every bug can
be fixed by AS developers of the framework; they don't have to learn
enough about Java and how to build the compiler.

-Alex

Mime
View raw message