incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Wasilewski <>
Subject Re: [FlaconJS] pseudo emitter algorithm
Date Fri, 30 Nov 2012 22:51:49 GMT
I'm trying to follow, but I feel the same.

My main confusion came from the one thing. I've got in my mind AST is 
just AST. Abstract by definition. It represents a code logic in abstract 
Why JS would collide with AS? Why the Falcon after AST coming back to 
AS? AST says, create class, create method, create method body, 
expression and evaluate it.
And now if JS is a target should have grammar definition how to create a 
class, method and represent evaluation. Am I missing a point of 
compilers, parsers etc?

On 11/30/2012 7:41 PM, Michael Schmalle wrote:
> Ok, I'm a bit confused but my brain is probably going to explode any 
> minute and that is about all from me for a bit.
> I'll just sit back and see if any other conversations come up about as 
> -> js. Maybe I'm crazy and just want to create more work for myself.
> Maybe the way it stands ABC -> js is good enough for now?
> Mike
> Quoting Alex Harui <>:
>> On 11/30/12 11:05 AM, "Michael Schmalle" <> 
>> wrote:
>>> Quoting Gordon Smith <>:
>>>> I don't object to generating a data structure for V11, but I think
>>>> that it makes more sense to do that as a second phase after ABC
>>>> generation is working. Otherwise there are a lot of moving parts and
>>>> progress will be slower.
>>> Correct me if I'm wrong Alex, but Gordon, I think Alex was talking
>>> about JavaScript data structures produced during crosscompile of MXML.
>> No, for both AS and JS so we have the same code paths.  But fear not, 
>> the
>> the work I did last year has a switch and all the old code paths are
>> retained.
>> I accept Gordon's argument that we can finish MXML handling faster by
>> getting Falcon to generate the old code patterns.
>> -- 
>> Alex Harui
>> Flex SDK Team
>> Adobe Systems, Inc.

View raw message