Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: flex-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <20121130124556.21035qrwp48zaitw@teotigraphix.com>
Date: Fri, 30 Nov 2012 12:45:56 -0500
From: Michael Schmalle <apache@teotigraphix.com>
To: flex-dev@incubator.apache.org
Subject: Re: [FlaconJS] pseudo emitter algorithm
References: <CCDE2D33.4946B%aharui@adobe.com>
In-Reply-To: <CCDE2D33.4946B%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 8:56 AM, "Michael Schmalle" <apache@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