`import` and aliasing bindings

Domenic Denicola domenic at domenicdenicola.com
Fri Dec 28 09:16:26 PST 2012


On Dec 28, 2012, at 11:54, "David Herman" <dherman at mozilla.com> wrote:

> On Dec 28, 2012, at 8:32 AM, Domenic Denicola <domenic at domenicdenicola.com> wrote:
> 
>>> Dave and Sam may have a different answer, but I'd answer that the aliasing semantics follows from a module system's role as (among other things) a name spacing mechanism.
>> 
>> This idea of modules as namespaces is a very interesting one I hadn't considered. My experience is with C++/C# namespaces, and with ES5 modules. With only this experience, the two concepts seem worlds apart. Are there other precedents where something by the name of "modules" acts like C++/C# namespaces, e.g. Ruby or Python?
> 
> There are indeed. Scheme and ML are examples. (Erlang and Haskell aren't really relevant since their bindings are immutable.)
> 
>> If not, perhaps the feature should be renamed to avoid confusion?
> 
> The word "namespace" flies around with *many* meanings -- you won't get very far arguing about its true meaning. But in terms of language features, ES6 modules are far closer to the historical precedent of language features known as "modules" rather than language features known as "namespaces."

Ok, I feel a bit better. It might be worth debating which "history" the messaging should be based on, i.e. more academic or functional languages vs. ones ES5 programmers are familiar with. But this is not that important; it's just messaging.

>> You could argue that "most" ES programmers aren't using modules today, so preserving the intuitions of and making refactoring easier for that minority isn't valuable. You might be correct, but I think the most avid early adopters who will drive ES6 forward are precisely the ones using ES5 modules. Furthermore, many of those not using modules are using "namespaces" via global object hierarchies, which (without `with`) have no aliasing properties.
> 
> The aliasing isn't observable for immutable bindings, only for mutable ones. In my experience, all of the module exports I've seen from NPM modules I've used were immutable.

This is amusingly tied to the single-export question. I.e. `module.exports =` produces a single immutable export (with mutable properties, see e.g. http://npm.im/glob), but all `exports.foo =` exports are mutable. Nobody does `Object.defineProperty(exports, "foo"', ...)` really. So most exports in npm are immutable… but maybe not for the reason you'd expect.


More information about the es-discuss mailing list