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
