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:31:13 GMT


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

>
>In my ignorant view right now I would say the goal is to make the MXML
>compiler have a backend for the framework API hooks, this would be correct
>in my head, the right way to direct.

Well, better abstraction is probably always good.  I don't know if the
framework abstraction can be completely encapsulated in a "backend".  I
think there is some resolving going on during the building of the AST that
required knowing what namespaces and classes are being used for data
binding.  So right now there are several things dictated in the
-config.xml.  IMO, it would be just as fine if all of the output
differences were defined in the -config.xml file so that there was just
one backend for mxml-children-as-data.  The name of the flag has meaning:
I think the goal is to not have the compiler generate code for MXML, but
rather generate data that the framework can turn into code.

Then you could compile your app with a flex-config.xml and switch to a
feathers-config.xml and it wouldn't change too much of the internal logic.

There is a potential runtime advantage to MXML as data as well.  With
MXMLC, all of the generated code is run once (and in Flash/AIR
JIT-compiled once as well) which is wasteful.  With MXML as data, there is
no generated code to run and JIT compile once, the code that "interprets"
the data gets run many times which is a better use of JIT compilation and
supposedly the runtime optimizations in the browser.

>
>I'm only guessing right now but some of my guesses have worked out pretty
>well. :)

Yes they have, and I'm very interested in what you will come up with in
this regard.

Thanks,
-Alex

Mime
View raw message