Quoting Alex Harui <aha...@adobe.com>:
On 11/30/12 9:45 AM, "Michael Schmalle" <apa...@teotigraphix.com> wrote:
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.
OK, I wasn't sure where the dividing line is around AST. Yes MXML nodes are
in the parse tree, but appears to be a different set of nodes than what AS
generates.
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.
You could be right, but I've been in
org.apache.flex.compiler.internal.as.codegen.MXMLClassDirectiveProcessor. I
don't see it using reducers/emitters/JBurg, I see it setting instructions
directly. But I might be missing something.
Take the below for instance;
MXMLFileNode(MXMLFileID) ""
MXMLDocumentNode(MXMLDocumentID) "flash.display.Sprite"
MXMLInstanceNode(MXMLInstanceID) "spark.components.Label" id="lbl"
MXMLPropertySpecifierNode(MXMLPropertySpecifierID) "x"
MXMLIntNode(MXMLIntID) "int"
MXMLLiteralNode(MXMLLiteralID) 100
MXMLPropertySpecifierNode(MXMLPropertySpecifierID) "y"
MXMLIntNode(MXMLIntID) "int"
MXMLLiteralNode(MXMLLiteralID) 25
MXMLPropertySpecifierNode(MXMLPropertySpecifierID) "text"
MXMLSingleDataBindingNode(MXMLDataBindingID) "DataBinding"
MemberAccessExpressionNode(MemberAccessExpressionID) "."
IdentifierNode(IdentifierID) "model"
IdentifierNode(IdentifierID) "labelText"
We have access to that tree when parsing. Instead of thinking we have
to parse this INTO ActionScript AST, we can think of this as MXML AST.
My point is, we would create a .js generator for MXML dialect. It
"might" even be adeventagious for us to create this implementation
becasue we "could" treat some parts of MXML differently than a plain
ole ActionScript class.
So we do have the AST at the same exact point we have ActionScript
AST. I was never saying MXML AST was ActionScript. I was saying we
have MXML AST to work with, and working with it's AST by not being
converted to ActionScript could actually be a bonus.
Note: There is nothing different about ActionScript AST when I go to
traverse it's tree. There will a a walker that knows how to traverse
the tree based on .as sematics. The same can happen for .mxml, a
woalker will know it's semantics and walk the tree correctly based on
MXML.
Also note, this is basically what JBurg does and produces. We just
want total control so there dosn't need to be experts on JBurg to fix
bugs with tree walking.
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
