ModuleImport

Marius Gundersen gundersen at gmail.com
Fri Jun 27 15:00:38 PDT 2014


On 27 Jun 2014 21:29, "Andreas Rossberg" <rossberg at google.com> wrote:
>
> Note that the other half of my argument was that "real" modules are
> only worth the complexity when they provide checking _consistently_.
> That is, it shouldn't matter whether I write
>
>   import {f, g, h} from "url"
>   f(); g(); h()
>
> or
>
>   module M from "url"
>   M.f(); M.g(); M.h()
>
> These should be freely interchangeable -- the programmer shouldn't
> need to pick between getting import checking but polluting the scope
> and making uses less readable, or the other way round. The current
> semantics falls short on that, it doesn't check in the latter case.
>
> So from my perspective, that would need to be fixed as well. Which
> would be fairly easy.
>
> /Andreas

And this is yet another counter argument to the default export. If the
default export is an object with properties (or a function with properties,
which I quite common in npm) then there is no static checking of those
properties. So with today's spec there is one way to get static checking
and one ways (default)  to not get static checking.

Marius Gundersen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140628/6569b88c/attachment.html>


More information about the es-discuss mailing list