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