Module naming and declarations

Andreas Rossberg rossberg at google.com
Thu May 2 07:47:06 PDT 2013


On 1 May 2013 00:01, David Herman <dherman at mozilla.com> wrote:
> On Apr 29, 2013, at 6:34 AM, Andreas Rossberg <rossberg at google.com> wrote:
>
>> ...you are generally assuming the use of some package manager. This
>> is a fairly significant assumption, that I wished I had heard being
>> made explicit in any of the previous discussions. AFAICT, it is key,
>> and without it, your proposal cannot fly. Not in a world with tens of
>> thousands of module releases, anyway.
>
> Not only is this wrong -- it'll be just fine to use ES6 without package managers -- but your proposal does not make any material difference in the relative dependence on package managers.

I don't see how logical names can possibly make sense without at least
a rudimentary manager that maps them. Otherwise they are just physical
names.

My point on the topic of external naming is that the language (1)
should not prescribe any specific naming scheme; (2) should not
willfully violate URI semantics; (3) should properly separate it from
internal naming.

Package managers are great, and I agree that they will (and should)
become part of the eco system. But leave design decisions to them, and
don't limit their options a priori. I'm not sure why we even disagree
on that.


>> More specifically, everything should still play nice with standard web
>> mechanisms. For me, the web platform implies that I should be able to
>> address modules as remote resources (it's a choice _not_ to use that
>> mechanism). That requires that the system allows proper URLs as module
>> identifiers.
>
> Fully agreed, and if it wasn't clear, the current system does completely support this. You can use a URL as a module name. In the default browser loader, you can choose to import a module from an explicit URL:
>
>     import { $ } from "http://my.cdn.com/jquery/1.9";
>
> and it will use that URL both as the logical name and as the place to go and fetch the bits.

OK, great! Can I also use such URLs for module definitions then?

> If you don't use an absolute URL, it treats it as a path, which defaults to loading as a source file from a relative URL derived from the module name.

And here we get to the core of the problem. Namely, how do you
interpret relative and absolute here? URLs have a very clear
semantics: everything that isn't absolute is relative _to the
referrer_. So far, everything I have seen in any of the recent module
specs or presentations is a blunt violation of these semantics.

In particular, as I mentioned before, you _cannot_ make "a" mean
something different than "./a" without violating URLs [1,2]. Yet that
is not only what you envision, it is what you de facto _prescribe_
with your proposal. I think that's simply a total no-go.

[1] http://tools.ietf.org/html/rfc3986#section-4.2
[2] http://tools.ietf.org/html/rfc3986#section-5.2.2


>> That does not mean that logical names have to become unreadable or
>> awful to type. Just that they are slightly more explicit. A schema
>> prefix -- say, jsp: for a random strawman -- is good enough and should
>> not offend anybody in terms of verbosity. (If it did, then I'd have
>> little hope for the evolution of the web platform. :) )
>
> First, let's be clear: this is literally an argument over the surface syntax of public module names, nothing more. You're arguing for the universal  addition of a few characters of boilerplate to all registered module names. That's just bad ergonomics for no gain. Not only that, it hurts interoperability with existing JavaScript module systems.

I don't see how it hurts interop. It just means that you have to find
a convenient _and_ proper way to embed a logical name space into URLs.
I proposed using a schema, but anything that is compatible with URL
semantics is OK. Just taking AMD-style strings verbatim is not.

It is not something which you can justify with AMD/Node precedence
either, since AFAICT these systems do not have the notational
overloading between logical paths and URLs that you propose.


> There's a reason why the existing systems favor lightweight name systems. They're nicely designed to make the common case syntactically lighter-weight. And they absolutely can co-exist with naming modules directly with URL's.

Sure they can coexist. But please not by bastardizing URL semantics.

/Andreas


More information about the es-discuss mailing list