Hi, >> 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? >> >> > No, I *do* talk about the "intermediate" code, as I see it as the *primary* > compilation result, and the production/release code as a derived artifact. > The former is the code developers see during debugging their application. > Nobody cares about how the production code looks like as long as it works, > it concise and performant.
That's where we differ in our approach, apparently: I think of the JS code as a replacement for the bytecode that feeds the Flash VM. Nobody but compiler/framework devs debug bytecode. And in my view, nobody but compiler/framework devs should (need to) debug Flex JS. The framework should "just work" for application devs. Their development (debugging) is in AS (Flash Builder), JS is just an output format, like bytecode if they choose to deploy in the Flash Player. This makes the release js (calling that a "derived artifact" is a bit dismissive, as it is the primary product of my effort). While it was fun, I think we have been at this for long enough. I have said all I possibly can on the subject and nothing you've said convinced me that -- other than being "different" and "not what you would choose" -- my approach is fundamentally wrong. I think I have backed up my position with a solid proof on concept. I will be spending my time improving and expanding that proof of concept and, in time, ask the community if my (and hopefully other's!) contributions are worthy to be included in the Flex SDK. Or, if someone does manage to convince me that another approach is better (e.g. FlexJS, or a tangible AMD implementation), I'll put my efforts into helping get that out of the door. EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl