On 19 November 2011 04:26, Patrick Mueller <[email protected]> wrote:
> On Fri, Nov 18, 2011 at 13:23, Andrew Lunny <[email protected]> wrote: > > The discussion, to my mind, isn't AMD vs CommonJS/Node but an explicit > > function-for-scope (explicit define) versus an implicit/generated > > function-for-scope (generated define). I think scoping is one of the most > > important tools a JavaScript programmer has, and hiding it away as > > something that gets generated as part of a compile-step muddles the > > abstraction layers, and makes programs harder to debug and reason about. > > I don't ever remember seeing anyone in Node-land complaining about the > hidden boilerplate. The boilerplate is defined here: > https://github.com/joyent/node/blob/master/src/node.js#L522 . Can you > provide some links to conversations concerning this with Node? > That file loads the core node.js module (http, file, etc) into the node binary at compile time. It doesn't affect userland code that is required at runtime - this is the code you're looking for: https://github.com/joyent/node/blob/master/lib/module.js#L362-433 which ultimately resolves to https://github.com/joyent/node/blob/master/src/node_script.cc#L276-279 There's no boilerplate added to user code, the user code is executed through either runInThisContext or runInNewContext, each of which is tied to a handle to V8. Node has a very clear execution model which we're unable to match, because of the constraints of our environment. > Rather, I think Nodesters probably *enjoy* not having to write the > boilerplate, and knowing they get a "free" closure-per-file without > any ceremony. I know I do. This experience matches other programming > languages I've dealt with over the years, which provide some amount of > "file private" capabilities (eg, static in C). Node is an independent execution environment tied directly to a single Virtual Machine. PhoneGap/Callback targets multiple execution environments, each of which has the constraints of a browser environment with its own scoping rules, most of which are using different VMs, that we do not have direct access to. If we had `instance_eval` and `class_eval` then we could make the code as pretty as Rails, but we don't and we won't. A digression on your digression, but this thread's already off track: there is a long-running discussion on the node mailing list about coroutines, or libraries that would implement coroutine functionality by transforming code at build-time. While a vocal minority is in favor of such an approach (see the node-fibers and streamlinejs) for concision and perceived readability, the core team and most experienced node developers reject these libraries as obscuring the execution model for no substantial increase in expressiveness. I wonder if there's a lesson there :)
