Module naming and declarations

Jason Orendorff jason.orendorff at gmail.com
Tue May 7 10:18:50 PDT 2013


On Mon, May 6, 2013 at 7:40 PM, Anne van Kesteren wrote:

> On Mon, May 6, 2013 at 4:39 PM, Jason Orendorff wrote:
> > [...] aren't *all*
> > other URLs a script deals with, including the existing APIs for
> > loading other scripts (adding a <script> tag or loading the code with
> > an XHR), resolved relative to the document base URL?
>
> Typically the entry script's base URL, which can be different in
> cross-document scenarios. And for XMLHttpRequest it's the document
> associated with its constructor object (which annoyingly is somewhat
> different from the rest).
>

Oh, interesting.

...reads a lot of spec text...

OK, check my work here: For resolve hooks, there's no entry script. The
loader calls the resolve hook asynchronously, from an empty stack. Or,
empty except for the loader implementation. Since we're talking about the
browser's default resolve hook, that's not a script either. No user code is
executing.

Tentatively I still think what XHR does is right for loaders. Each Loader,
like a Worker or DOM node, should have its own base URL and use it
consistently. It seems unhelpful for a cross-document call elsewhere on the
stack to affect System.load(), causing modules to be loaded from the wrong
place. Note that loaded modules are cached, so the oddness would persist.

I dunno, Anne. I'm sure I'm not the first n00b to say this, but caring
about what code is at the bottom of the stack is creepy already. The "entry
script's base URL" convention seems bad, even if we could follow it.

-j
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130507/513fea70/attachment.html>


More information about the es-discuss mailing list