On May 27, 2010, at 4:19 PM, David Herman wrote:

The problem is that, in the space of module names, the current Simple
Modules strawman introduces a hazard of inadvertent name capture

Yes, implicit linking means that you can mis-link. In my mind, the questions are how much of a hazard this really is, how much architecture it would require imposing on programmers to address it, and what we lose if we do that.

Many of your suggested alternatives involve explicit linking. Explicit linking certainly has its appeal: it lets you really say exactly what you mean. But there are massive differences in the convenience of explicit and implicit linking systems. Years of PL research and experience have demonstrated that explicit linking tends to be unwieldy and inconvenient.

Last I checked, CommonJS (ignoring packages, which NodeJS and others are avoiding) uses implicit linking via the filesystem.

This is extremely common -- see Python and many other languages. It is so convenient than any explicit-linking system delivered in an Ecma de- jure standard will beget implicit linking systems built on top (like CommonJS's) in the wild, imposing costs that we could head off by standardizing implicit linking. Which simple modules proposes.

Hazards involve trade-offs. There's no risk-free solution. It is hard to prove decisively that implicit linking won't lead to some bad name dependency bug down the road -- it could. But I argue that it's inevitable in the wild if we try to impose explicit linking, so we should not standardize around it.

Rather, we should try to standardize a module system people will use well, which restores lexical scoping all the way up (ridding us of the global object), which improves integrity (const exports, shallowly frozen if functions, etc.), and which does not instantly beget another module system (or non-standard systems) on its back for want of implicit-linking convenience.

/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to