Module naming and declarations

Sam Tobin-Hochstadt samth at ccs.neu.edu
Tue May 7 12:17:26 PDT 2013


[coming back to this a few days later]

On Thu, May 2, 2013 at 10:47 AM, Andreas Rossberg <rossberg at google.com> wrote:
> 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.

AMD works today in the absence of a package manager, and the logical
names are not physical names there either.

> 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.

(1) No "naming scheme" is prescribed here, unless you mean the
semantics of relative paths

(2) As I pointed out in the mail I just wrote in reply to Anne,
nothing violates URI semantics here.  Logical names are not URIs, and
thus treating them differently than URIs doesn't violate URI
semantics.

(3) Internal naming in the sense you mean is primarily a concern for
organizing code within a single lexical scope. This is a real issue,
but it's not nearly as pressing as the other issues here, and I think
we can safely defer it.

> 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.

I think we agree on this.

>>> 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?

I don't know what you're asking here.

>> 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

No, this is not correct.  Neither "a" not "./a" are URLs, and thus
treating them differently does not violate the semantics of URLs.

>>> 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 hurts interop because AMD-style modules are named as "a/b" and not
"jsp:a/b". A required prefix would therefore require impedance
matching somewhere.

> 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.

Both AMD and Node *automatically* convert module names like "a/b" into
URLs (in the AMD case) and file paths (in the Node case).

>> 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.

Again, these are not URLs.  You can't on the one hand complain that we
aren't using URLs for names, and then on the other hand complain that
our treatment of logical names doesn't follow the rules for URLs.

Sam


More information about the es-discuss mailing list