Module naming and declarations

Jason Orendorff jason.orendorff at gmail.com
Fri May 3 15:43:53 PDT 2013


On Wed, May 1, 2013 at 11:59 PM, Kevin Smith wrote:
> On Wed, May 1, 2013 at 7:08 PM, Jason Orendorff wrote:
>> On Wed, May 1, 2013 at 9:18 AM, Kevin Smith wrote:
>>> - Dave, your argument that URI's as a naming mechanism is a "failure"
>>> cherry-picks cases where URIs were obviously overkill.
>>
>> What counterexamples should David have mentioned?
>
> Well, it's Dave's job to come up with one, not mine ; P

Wait, we've had a misunderstanding somewhere. If you think David's
argument cherry-picks cases, then you must have in mind some cases he
didn't mention that contradict his point. That's what I'm asking for.

> A clean separation between modules and packages will give us the freedom to
> experiment with different approaches to inter-package dependency resolution
> (IPDR, so I don't have to repeat it later).  At the base level, we just want
> URLs.

Do we? It seems to me that "filenames as import-specifiers" is a
design option that has been available to, and rejected by, all of the
JS module systems and all recent programming languages, except PHP.*
And the reason seems obvious enough: hard-coding a library's location
into every import site is bad.

> Loader hooks can then be used to give special semantics to URI subsets,
> or even to provide AMD-style URL overloading.

If we don't expect loaders to treat these names as URLs or respect URL
resolution semantics, then they aren't URLs, and it's bogus to call
them URLs.

-j

*In fairness to PHP, I'm told `include "filename.php"` is now
considered bad style. Autoloaders are preferred.


More information about the es-discuss mailing list