Module import/export bindings

Caridy Patino caridy at gmail.com
Sun Mar 15 18:26:09 UTC 2015


inline

On Sun, Mar 15, 2015 at 11:42 AM, Kyle Simpson <getify at gmail.com> wrote:

> > Regarding the internal server error
>
> Ahh, thanks. Yeah, not only is it confusing to see the "edit" button, but
> especially since clicking it asks you to login to the site as if to verify
> your authorization to do such. :)
>
>
> > I guess you'd intended to write export {foo as default} instead of
> export default foo...
>
> Well, no, until your reply I didn't realize there was a difference in the
> two! Yikes. That's… surprising.
>
> Just to make sure I'm crystal clear… in my original example:
>
> ```js
> var foo = 42;
> export default foo;
> foo = 10;
> ```
>
> That exports a binding only to `42`, not `10`. But:
>

correct


>
> ```js
> var foo = 42;
> export {foo as default};
> foo = 10;
> ```
>
> That exports a binding to `foo` so the importer sees `10`. Correct?
>
>
correct


>
> > All three assignments throw a TypeError exception
>
> Thanks for the clarifications!
>
> 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?
>

that's well documented as part of the description of the namespace exotic
object.


>
> Also, are these errors runtime or static? I'm guessing from the spec text
> you quoted they're runtime. If so, was there a reason they couldn't be
> static?
>

named imports will throw as part of the static verification, but namespaces
can only throw during runtime due to the nature of the exotic objects.


>
> -----
>
> I have some modules where the intentional design of the API has been for a
> consumer to be able to change property value(s) on the public API, and the
> module would behave differently corresponding to those values, almost like
> if they were "configuration".
>

use a method to mutate internal named exports.


>
> I take it there's no way to do this directly on the module namespace (even
> with the namespace import) with ES6 modules? So basically to do that I'd
> have to export an object (called like `config`) that holds such
> intentionally mutable properties?
>
> Similarly, the (much maligned but still somewhat popular) pattern of
> having module "plugins" which attach themselves on top of an existing API…
> sounds like this pattern is also not supported?
>

plugins are orthogonal to modules, modules CANNOT be extended, but you can
plug things into objects exported from a module.

/caridy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150315/0a011d83/attachment.html>


More information about the es-discuss mailing list