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

Reply via email to