I think I agree with everything you said, Alex. Here's my take:
AS->ABC is already done in Falcon, modulo some bug fixes. AS->JS is kinda done in FalconJS but needs work and we may want to change it to emit different JS patterns. MXML->ABC is 80% done in Falcon and worth completing. I'm working on determining what works, what doesn't, and fixing problems. MXML->JS doesn't exist and is not the way to go. MXML->datastructure is a good idea. Alex will do it first for interpretation by JS and later for interpretation by an ABC library written in AS. - Gordon -----Original Message----- From: Alex Harui [mailto:aha...@adobe.com] Sent: Friday, November 30, 2012 3:04 PM To: flex-dev@incubator.apache.org Subject: Re: [FlaconJS] pseudo emitter algorithm OK, what did I write that is confusing everybody? IIUC, MXML is parsed into a different set of nodes which are then visited in the tree walk to generate ABC codes directly. When compiling the AS in an MXML script block or a .AS file, the AS AST nodes go through Jburg and eventually become ABC. FalconJS only overrides the AS AST nodes to generate JS. I don't think it will generate anything for MXML, but I haven't tried it. MXML -> ABC is mostly or all in MXMLClassDirectiveProcessor.java. I think FalconJS will have to swap/overlay/override what that class does to generate JS. What MXML currently resolves to in ABC is the equivalent of a bunch of functions that construct the tags in the MXML. For many reasons which I have mentioned before, I am planning to change the ABC that it generates to generate a data structure. And then FalconJS will need to generate the same data structure in JS. Does that help? On 11/30/12 2:51 PM, "Daniel Wasilewski" <devudes...@gmail.com> wrote: > 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 form. > 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 <aha...@adobe.com>: >> >>> >>> >>> >>> On 11/30/12 11:05 AM, "Michael Schmalle" <apa...@teotigraphix.com> >>> wrote: >>> >>>> Quoting Gordon Smith <gosm...@adobe.com>: >>>> >>>>> 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. >>> http://blogs.adobe.com/aharui >>> >>> >> > -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
