Module naming and declarations

Domenic Denicola domenic at domenicdenicola.com
Fri Apr 26 07:35:34 PDT 2013


From: Kevin Smith [zenparsing at gmail.com]

> What you propose, with "logical names", is a global namespace of short human-readable names with *no* conflict resolution authority.  How do you see that working?  From a namespace perspective, how is that any different than hanging identifiers off of the global object, as we do today?  I'm not understanding how this strategy will facilitate namespace coordination.  I can only see it leading to namespace confusion.

Indeed, I must second this question. (This causes me some cognitive dissonance, since from a Node.js/AMD perspective that I work in daily, string IDs seem great, so I'm not sure what I'm arguing for ^_^.)

The way I think of this is that it's conflating packages and modules. In current practice, packages have names that are registered in a global registry, and they are represented in the module system by a "main module" for that package. The wiring that allows `"${packageName}"` to resolve to the URL for the main module of `packageName` is part of the loader; in Node.js for example it does directory climbing through `node_modules` and inspects `package.json`s for their `"main"` values.

In this way, modules do not have any globally-known names at all; their names are derived entirely from URLs (in the form of relative file paths).

I made this point in [a recent presentation on client-side packages](http://www.slideshare.net/domenicdenicola/client-side-packages), slides 6 and 7.

Curious if others agree with this or if I'm totally off base as to how this fits into the discussion...


More information about the es-discuss mailing list