[FalconJx] status update
Hi, An update: Mike and I are coming along nicely with FalconJx. - there are now tests for all but a handful of AS language features, and most of these pass, even ;-) - the 'goog' JS implementation is close behind, with most 'missing' JS features at least provisionally implemented in the compiler. Of course we need to actually implement these features in JS, but one step at a time. - created an alternate (non-'goog') emitter, provisionally named 'AMD', just because I could (and to store the other way to handle default parameters for posterity). Created a few tests for this emitter, as well. Next up: - a lot of refactoring (Mike?) - a lot of TODOs to work through - get the compiler to accept AS files and spit out JS files (?) - create functional tests for the AS input and JS output, and match these... ideas? - work with Alex to get FlexJS to work with FalconJx so we can test the whole intended 'goog' workflow, include 'my' Publisher script - ... - profit! Have fun, EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: [FalconJx] status update
Quoting Erik de Bruin e...@ixsoftware.nl: Hi, An update: Mike and I are coming along nicely with FalconJx. - there are now tests for all but a handful of AS language features, and most of these pass, even ;-) - the 'goog' JS implementation is close behind, with most 'missing' JS features at least provisionally implemented in the compiler. Of course we need to actually implement these features in JS, but one step at a time. - created an alternate (non-'goog') emitter, provisionally named 'AMD', just because I could (and to store the other way to handle default parameters for posterity). Created a few tests for this emitter, as well. Next up: - a lot of refactoring (Mike?) Yes, this week was my week off with music, audio and 3D. Need to give that right brain some love, or is it left? I don't know either way I will be back... ;-) You have done a kick ass job Erik and I am very gratful for what you did this week. But your right, there needs to be another crunch and pack. ;-) - a lot of TODOs to work through Not really hard, just knock them down like well you know. - get the compiler to accept AS files and spit out JS files (?) Well, it pretty much already does in a way. I need to work on this but now that Roland is a comitter, we have some ideas about this are that we want to explore. A modular compiler, so I might use this front end and back end as a prototype for this new path. - create functional tests for the AS input and JS output, and match these... ideas? I have done something similar in a past life, I will think about this. - work with Alex to get FlexJS to work with FalconJx so we can test the whole intended 'goog' workflow, include 'my' Publisher script - ... - profit! Have fun, EdB Mike -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl -- Michael Schmalle - Teoti Graphix, LLC http://www.teotigraphix.com http://blog.teotigraphix.com
Re: [FalconJx] status update
On 1/10/13 6:05 AM, Erik de Bruin e...@ixsoftware.nl wrote:
- work with Alex to get FlexJS to work with FalconJx so we can test
the whole intended 'goog' workflow, include 'my' Publisher script
Excellent news! In between TLP and release stuff I have been slowly
plugging away at getting FalconJS to output goog code for both AS and MXML.
I've done a bunch of changes to the frameworks files to make it easier to
deal with the MXML output. I'm at the point of finally trying to get it all
to run. Some things like data-binding {} syntax is still not supported but
you can add a bead to bind something simple.
I stayed with FalconJS for two reasons: 1) I didn't know how long Erik and
Mike would take and 2) I felt like I needed to understand FalconJS better so
we can truly understand the trade-offs between FalconJX and FalconJS. So
far, I'm becoming more convinced that the AST tree walker in FalconJX will
suit our needs better. For example:
-FalconJS has some really complex constructor handling code. That's because
initialized instance properties in AS are moved to the constructor.
However, in JS that isn't required as we can initialize them on the
prototype (unless there is some subtle rule about how arrays get
initialized) so no need to jump through all of these hoops in FalconJX.
-FalconJS has what I would call top-down tree walking for MXML parsing. But
then if you hit AS code in an event handler or script block you have to send
that stuff through the BURM.
-The BURM is still an impenetrable fortress for me. So far I haven't had to
change it and have sort of figured out how to debug into it, but if
GoogleClosure is going to do the same sort of optimizations for us, it isn't
clear we really need it. The only area we might need something like it is
for future optimizations of data-binding output code. Current data-binding
code is very general and highly inefficient. We want to someday output
different patterns of data-binding code in different situations (like in an
item renderer or when bound to a data model). This will require
understanding more about what the code is trying to do. But Falcon already
has the basic pieces for this so maybe we can leverage it as needed.
So, anyway, I hope to check in this week or weekend and then will eagerly
look forward to FalconJX growing up to replace it.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
