Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: flex-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Message-ID: <20121130133345.10301q5lr8sndde1@teotigraphix.com>
Date: Fri, 30 Nov 2012 13:33:45 -0500
From: Michael Schmalle <apache@teotigraphix.com>
To: flex-dev@incubator.apache.org
Subject: Re: [FlaconJS] pseudo emitter algorithm
References: <CCDE35FA.4947D%aharui@adobe.com>
In-Reply-To: <CCDE35FA.4947D%aharui@adobe.com>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=ISO-8859-1;
 DelSp="Yes";
 format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
User-Agent: Internet Messaging Program (IMP) H3 (4.3.11)

Quoting Alex Harui <aharui@adobe.com>:

>
>
>
> On 11/30/12 9:45 AM, "Michael Schmalle" <apache@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