Quoting Alex Harui <aha...@adobe.com>:
On 11/30/12 8:56 AM, "Michael Schmalle" <apa...@teotigraphix.com> wrote:
My only question was, were the engineers doing anything specific with
resolutions and such with the SWF.
My guess is that the engineers were just leveraging the file output portion
of Falcon. I pondered whether having the SWF constant pools around would
make for tighter code in JS, but I don't think so.
The fact that jangaroo does it with AST is good enough for me to get
going on a prototype. I was just trying to see if there was anything
where I am not reinventing the wheel. But I will, if that is the only
way to go since the API is externally different then jangaroo.
So is your plan to rewrite the generator so it doesn't reduce the code to
SWF entities via JBurg?
I don't know yet. My intuition is telling me I don't have enough facts
right now. Basically I wanted to make something inline with jangaroo's
JSCodeGenerator with the visitor pattern. I have written this type of
ActionScript code generation before, so I am no stranger to it.
My thought is this. If we rewrite the code generation using
AST/Definitions framework it will be 10 times easier to write custom
code generation backends because we will have created a tight and
clean API to do so. IE Java or whatever. This is not saying it's easy
but you would rip out 2 dependencies doing this, SWF and JBurg. This
allows a lot more possible code contributions down the road with those
two monsters out of the pie.
My advice to myself and others is this. Write all the js you want
against how the compiler spits it out right now. If I go the route and
if there are any others that want to join in, we will meet at the same
exact code generation.
Once there is a semi stable implementation using the new generator
that produces the code you want, we can steer the js in a new
direction if needed.
A note about MXML, since the parse DOES create and AST during parsing
of an MXML file, and MXML uses the IDefinition API, we can catch MXML
code at the same intersection we are getting the AS code at, the AST
definition stage.
Actually this might work even better because both .as and.mxml are on
the exact same playing field at this point in the parsing.
The problem that MXML is not converted to ActionScript is mute since
we are using the AST/Definitions... problem solved.
Mike
Using the IDefinition API, with loaded SWCs gives you member and class
resolotuion so I might actually start with that higher level and not
strictly IASNode parser nodes.
It occurred to me that I think MXML does not go to AS or AST, it goes
straight to ABC, so we'll be customizing that code in some way as well.
I doesn't got to straight ABC, it does go to AST then ABC. Everything
has to be AST first to then go to JBurg ABC reducer.
Alex, this package is the key *org.apache.flex.compiler.tree.mxml*.
Mike
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
