incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik de Bruin <>
Subject Re: [FalconJS] concepts
Date Thu, 29 Nov 2012 14:38:15 GMT
Actually, the third argument of 'adobe.extend()' is what can probably
considered "the rest" of the output of the JSEmitter (yes, Mike, it
did make a little more sense). And that "the rest: is a "simple"
object literal, which can easily be parse (as the 'extend' method

If you want to change stuff on the JS side, all you need to do is
replace the implementation of the 'adobe' object methods, leaving the
"API" (basically 'extend' and a few utility methods) untouched. I
don't suggest this as a permanent solution, but while better minds
than mine are working on getting the compiler under control it does
provide a method to experiment with the JS side of things.


On Thu, Nov 29, 2012 at 2:48 PM, Daniel Wasilewski <> wrote:
> On 11/29/2012 1:36 PM, Michael Schmalle wrote:
>> Laymans; A SWF is created for all classes just like in MXMLC, there is a
>> visitor pattern that is used that traverses the internals of the ISWF. As
>> each of the elements in the SWF are traversed (classes, methods, members
>> etc) calls to the JSEmitter and other classes happens and the js is created
>> during the traversal.
> And this is the place 'JSEmitter ' that has the JS grammar rules specified,
> but instead spiting out pure JS syntax it relies on little adobe.js that
> simplifies the process and grammar rules. Am I right? if so, How hard it
> would be to make it adobe.js independent, if too hard, adobe.js would be a
> subject to change/polishing up, we just need to know what fields JSEmiter is
> expecting to match.
>> JBurg is compiled to actually create the class and rules that does the
>> actual traversal logic through the SWF file.
>> Does that make more sense?
>> Mike

Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295

View raw message