From: Kevin Smith [[email protected]]
> 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...
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
