ModuleImport

C. Scott Ananian ecmascript at cscott.net
Fri Jun 27 09:36:22 PDT 2014


On Fri, Jun 27, 2014 at 9:07 AM, Andreas Rossberg <rossberg at google.com>
wrote:

>   - It removes the syntactic marker for binding a module identifier.
> That is problematic because (a) module identifiers come with extra
> static checks on their uses (or so I thought, see below), and it is
> (b) future hostile to lexical module declarations, because with those,
> only module identifiers could be used in certain contexts (e.g., on
> the RHS of an import-from). Thinking forward, I think it would be
> highly preferable to consistently mark all bindings of module
> identifiers with a 'module' keyword.
>

I disagree here.  I think certain people are too hung up on what is a "real
module" and what is an "object pretending to be a module".  For lots of
legacy code (think jquery), we have objects like `$` which are actually
both functions *and* modules (in the form of namespaces).  The JS community
can handle this.  Honestly, most of the fun features of "real modules" are
obscure corner cases anyway (like lazy binding).  We can deal with a few
oddball "modules" which are not actually module objects.


>   - Some want modules in the conventional sense, as encapsulated
> namespaces with named exports, which you can import and access
> qualified or unqualified, and where imports are checked.
>
>   - Some want modules in the specific pre-ES6 JavaScript style, where
> they can be any arbitrary JS value, and in the good old JavaScript
> tradition that checking doesn't matter.
>
> The current design (including the newest suggestions for imports)
> seems to please neither side, because it tries to be the former
> semantically, but wants to optimise for the latter syntactically. The
> main outcome is confusion.
>

I think the problem is somewhat different, in that certain people resist
the idea that some "modules" might not be actual modules.  I think we could
embrace that and the result would be *less* confusion (since we wouldn't
require a syntactic marker for "real module").  It will be rare for someone
to notice that `$.foo` is not lazily-bound, or that `$.module.path` (or
whatever) isn't actually defined.  If they care, they can file a bug
against jquery.  jquery should be able to either emulate the module
functionality (duck typing!  but this is one of the things that annoys me
about the current way lazy binding works) or decide that
backwards-compatibility or whatever is more important and ignore the issue.


>   - Either we think "real" modules are an improvement, and checking is
> important. Then the model and the syntax should be consistent about
> that. Moreover, checking needs to consistently apply, no matter how a
> module and its components are defined or accessed.
>
>   - Or we come to the conclusion that supporting the legacy singleton
> export model as a primary use case is a mandatory matter. Then we
> should drop attempts of building something in/semi-compatible, and
> limit innovation to making export and import declarative, and
> designing a loader API.
>

Again, I think it's the "either/or" mindset which is the problem here.  We
can actually have both.  Sometimes we won't be able to do strict checking.
 Sometimes we will.  We don't need to force everyone into the same mold.
 Let the author of the module decide how important static checking, lazy
binding, ease-of-use, etc, is and define their module appropriately.  (And
the same for the "importer of the module".)


> Quite honestly, I rather have no import checking than checking that
> only applies in some syntactic cases -- because that gives a false
> sense of security, harms refactoring, and/or encourages overuse of
> unqualified imports, hampering readability.


Again: is this what's hampering compromise?  Can't we let the module author
(and/or importer) decide the extent to which they think checking is
important?

Yes, modules will be a compromise design.  But it's a compromise design
because of *network effects* and *programmer preference*.  There are large
and useful codebases organized around different principles.  We can't force
them all into the same mold.  Programming is still an art form and a matter
of taste; let's go easy on the mandates.
  --scott (who actually thinks that current modules spec is not that bad,
although it could be slightly improved)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140627/6c0c2b40/attachment.html>


More information about the es-discuss mailing list