Module naming and declarations

Kevin Smith zenparsing at
Fri May 3 19:22:24 PDT 2013

> Wait, we've had a misunderstanding somewhere. If you think David's
> argument cherry-picks cases, then you must have in mind some cases he
> didn't mention that contradict his point. That's what I'm asking for.
I gotcha - that's fair.  I concede the point though as not central to my

> > A clean separation between modules and packages will give us the freedom
> to
> > experiment with different approaches to inter-package dependency
> resolution
> > (IPDR, so I don't have to repeat it later).  At the base level, we just
> want
> > URLs.
> Do we? It seems to me that "filenames as import-specifiers" is a
> design option that has been available to, and rejected by, all of the
> JS module systems and all recent programming languages, except PHP.*
> And the reason seems obvious enough: hard-coding a library's location
> into every import site is bad.
First, I assume that you're just referring to inter-package dependencies.
 Relative paths are fine for a library's internal modules.

Second, I'm well aware of the issues you point out with using URLs or file
paths for inter-package dependencies.  I think URLs *can* perhaps do some
interesting things for us here which we haven't seen yet, but I'm not
arguing against using a flat namespace.

But (and this is the key) such a flat namespace must be layered on top of
URLs.  It cannot *overload* URLs as the current design attempts to do.  Why
not?  Because such an overloaded semantics would conflict with the
resolution semantics as defined by the platform in HTML, CSS, etc.  Truth,
beauty conceptual integrity, and all that good stuff. : )

The Dart designers came to a similar conclusion.  External files are
specified by URL, with a custom schema designating the "package" root.

    import 'package:mylib/mylib.dart';

Although note the lack of file-extension magic, and the fact that Dart does
not even pretend these are "logical names".

Should javascript do something similar?  Maybe.  Maybe that's something for
the platform to decide.  But in any event, that's not a discussion that we
can begin to have until *after* we have consensus on modules.

> > Loader hooks can then be used to give special semantics to URI subsets,
> > or even to provide AMD-style URL overloading.
> If we don't expect loaders to treat these names as URLs or respect URL
> resolution semantics, then they aren't URLs, and it's bogus to call
> them URLs.
By design, you can implement any kind of madness you want with loader
hooks, but *by default*:  URLs, baby ; )

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

More information about the es-discuss mailing list