One thing I was thinking about. How would debugging work ? Let's say I set a break point in my as3 code how will debugging the js output look like
Greets Alain On Jan 28, 2013 8:37 AM, "Erik de Bruin" <e...@ixsoftware.nl> wrote: > Hi, > > > entire library + application". My example was that you change a single > > file, but change it in a way that you add a dependency. Without > > re-generating deps.js, base.js could not know in advance that the newly > > We're talking AS -> JS cross compilation. So changing one file would > be changing one AS file. To turn that AS file into a JS file needs a > compilation step. The generation of 'deps.js' is part of the > compilation step. So, in the scenario we're discussing, the > regeneration is of no consequence. Also, more importantly, 'deps.js' > is only needed for the 'intermediate' output, not in the release > output. I think if we're going to be comparing anything, we should be > comparing 'production/release' code, not 'convinience/intermediate' > code, right? > > >> > and compile it with Jangaroo 3 and also deploy the output. What do you > >> > think? > >> > >> I enabled "View Source" on the Flash output, so you can grab the AS > >> source and put it through Jangaroo if you please. You can also pick up > >> Alex's FlexJS source and do the same with that.Might be interesting to > >> see what comes out and compare the various approaches when using a > >> different compiler. > >> > > > > Yes, I'll try to do that, but except from the deps.js file discussed > above > > I expect the difference to be rather small. > > So, if 'deps.js' is not needed -- like it's not needed in the > 'release' output of my proof of concept -- there really isn't any > practical difference between our approaches? > > > However, I still think it is better to consolidate than to offer too much > > to chose from (where it brings no benefit). And I'd still like to hear > your > > I'd love to consolidate, and I'm reading your Wiki pages with interest > on how to tackle some of the language inconsistencies between AS and > JS. I just wish that we could work together on code, instead of going > round and round on theory and relative merits of two different but > equal approaches. > > > opinion on my warning that the input language for GCC is a dialect of > > JavaScript (restrictions, extensions), not standard JavaScript. > > If by GCC you are referring to the compiler, [1] should answer your > question. The Google Tools (which include, but are not limited to, the > compiler) like to have their JavaScript in a 'pseudo-classical' > pattern, but that doesn't mean they won't gladly handle other > patterns, like "AMD". The JSDoc annotations are only there to help the > GCC do an even better job, but are not required for the code to > function as coded. What about the "input language for GCC" do you > regard as a dialect of "vanilla JS"? > > EdB > > 1: https://developers.google.com/closure/compiler/faq#restrictions > > > > -- > Ix Multimedia Software > > Jan Luykenstraat 27 > 3521 VB Utrecht > > T. 06-51952295 > I. www.ixsoftware.nl >
