<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">
<br>
</div>Wait, we've had a misunderstanding somewhere. If you think David's<br>
argument cherry-picks cases, then you must have in mind some cases he<br>
didn't mention that contradict his point. That's what I'm asking for.<br>
<div class="im"><br></div></blockquote><div><br></div><div style>I gotcha - that's fair.  I concede the point though as not central to my position.</div><div style> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">
> A clean separation between modules and packages will give us the freedom to<br>
> experiment with different approaches to inter-package dependency resolution<br>
> (IPDR, so I don't have to repeat it later).  At the base level, we just want<br>
> URLs.<br>
<br>
</div>Do we? It seems to me that "filenames as import-specifiers" is a<br>
design option that has been available to, and rejected by, all of the<br>
JS module systems and all recent programming languages, except PHP.*<br>
And the reason seems obvious enough: hard-coding a library's location<br>
into every import site is bad.<br>
<div class="im"><br></div></blockquote><div><br></div><div style>First, I assume that you're just referring to inter-package dependencies.  Relative paths are fine for a library's internal modules.</div><div style>
<br></div><div style>Second, I'm well aware of the issues you point out with using URLs or file paths for inter-package dependencies.  I think URLs *can* perhaps do some interesting things for us here which we haven't seen yet, but I'm not arguing against using a flat namespace.</div>
<div style><br></div><div style>But (and this is the key) such a flat namespace must be layered on top of URLs.  It cannot *overload* URLs as the current design attempts to do.  Why not?  Because such an overloaded semantics would conflict with the resolution semantics as defined by the platform in HTML, CSS, etc.  Truth, beauty conceptual integrity, and all that good stuff. : )</div>
<div style><br></div><div style>The Dart designers came to a similar conclusion.  External files are specified by URL, with a custom schema designating the "package" root.</div><div style><br></div>    import 'package:mylib/mylib.dart';<br>
</div><div class="gmail_quote"><br></div><div class="gmail_quote"><a href="http://www.dartlang.org/docs/dart-up-and-running/contents/ch02.html">http://www.dartlang.org/docs/dart-up-and-running/contents/ch02.html</a><br></div>
<div class="gmail_quote"><br></div><div class="gmail_quote" style>Although note the lack of file-extension magic, and the fact that Dart does not even pretend these are "logical names".</div><div class="gmail_quote" style>
<br></div><div class="gmail_quote" style>Should javascript do something similar?  Maybe.  Maybe that's something for the platform to decide.  But in any event, that's not a discussion that we can begin to have until *after* we have consensus on modules.</div>
<div class="gmail_quote"><div style><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">
> Loader hooks can then be used to give special semantics to URI subsets,<br>
> or even to provide AMD-style URL overloading.<br>
<br>
</div>If we don't expect loaders to treat these names as URLs or respect URL<br>
resolution semantics, then they aren't URLs, and it's bogus to call<br>
them URLs.<br>
<br></blockquote><div><br></div><div style>By design, you can implement any kind of madness you want with loader hooks, but *by default*:  URLs, baby ; ) </div><div style><br></div><div style>{ Kevin }</div><div style><br>
</div></div></div></div>