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 does).
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. EdB On Thu, Nov 29, 2012 at 2:48 PM, Daniel Wasilewski <devudes...@gmail.com> 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 I. www.ixsoftware.nl
