4 ms·
First, if you want to just use objects-as-prefixes, the way require(...) works in node today, that's easy to do: module m at "blah.com"; ... references
by samth 15y ago
First, if you want to just use objects-as-prefixes, the way require(...) works in node today, that's easy to do:
module m at "blah.com";
... references to m go here ...
We also want to support other use cases, like binding the exports to names available in your local scope. We understand that not everyone likes that style, but I don't think the language should mandate a particular side in that fight.
Second, the `module m at "URL"` form above is a definition of `m`. It's just that you're allowed to refer to that binding as an object too. Would you rather have:
module m at "example.com";
import m;
That just seems like unnecessary typing to me.
- substack 15y agoI mean why does `module` pull down resources? Shouldn't that be import's job?
- samth 15y agoThere are two reasons: 1. `module` is about defining the modules that you're using in your program, some of which might be remote resources. `import` is about bringing names into scope. 2. Using `module` this way lets you, the client, decide on names for modules, which means we don't have to rely on module authors to come up with and use naming conventions (net.substack.airport, anyone?). This feeds back into 1, where we use bindings to reference modules, even remote ones. Also, if a module is never referenced or imported, then the resources shouldn't need to be pulled down at all. So partly it depends on the way you look at things.