Module import/export bindings

Mark Miller erights at
Mon Mar 16 16:26:02 UTC 2015

Story is way too simple. JS const means constant, unchanging. By contrast,
import bindings, like const in C++, means "read-only view". This is *very*
different from constant.

Don't use the "const" analogy when changes are still observable.

On Mon, Mar 16, 2015 at 9:20 AM, Allen Wirfs-Brock <allen at>

> On Mar 15, 2015, at 9:43 PM, Domenic Denicola wrote:
> > From: es-discuss [mailto:es-discuss-bounces at] On Behalf Of
> Kyle Simpson
> >
> >> Would it then be appropriate to explain that conceptually the binding
> would otherwise indeed be 2-way, but that the immutable/read-only nature of
> the bindings is what prevents an outside mutation of a module's internals?
> That is, without such bindings (and errors), a module could be changed from
> the outside?
> >
> > I wouldn't really find this an appropriate explanation. That's kind of
> like saying "this building's 6th story would be blue, but the 5-story
> nature of its blueprints is what prevents you from accessing the 6th
> story." There just isn't any 6th story at all. (Similarly, there just isn't
> any defined [[Set]] behavior for module namespace objects at all. You could
> make up a plausible one, like pretending it would modify the original
> module's bindings, and write a revisionist history in which it was removed.
> But that's not really how the spec works.)
> the simple story:
> imported bindings are all `const` bindings.  Think of them as if if they
> were written
> ```js
> const import {a,b,c} from "foo";
> ```
> Allen
> _______________________________________________
> es-discuss mailing list
> es-discuss at

Text by me above is hereby placed in the public domain

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list