On 27/09/2016 10:28, David Teller wrote:
On 26/09/16 19:50, zbranie...@mozilla.com wrote:
So, it seems to me that we're talking about two aspects of module loading:
1) Singleton vs. per-instance
Cu.import allows us to share a single object between all the code that
references it.
ES6 modules are not meant to do that.
If I understand ES6 modules correctly, two imports from the same webpage
will return the same module instance, right?
How hard would it be to consider all chrome code (of a JSRuntime) as a
single webpage? That's pretty much a requirement for any module loader
we would use for our chrome code.
I don't see how you would do this, because the globals *would* be
different for different windows (ie 2 copies of browser.xul windows),
and for XPCOM components. Even if our module loader had magic that let
this all happen without duplicating the modules themselves, it feels
like all kinds of static analysis and tools that we'd be doing this for
would break (because modules could never assume that |window| was a
thing in their global, or that it was always the same, but the tools
would assume that they could).
3) The issue of loading the source code
All module systems need to load their source before proceeding. If I
understand correctly, ES6 modules rely upon the same network stack as
the rest of Gecko to load the source code, while jsm rely only upon the
much more limited nsIJar* and nsILocalFile.
You've not really given enough detail here to explain why this is a
problem. You can pass chrome and jar: URIs to an XHR (obviously you get
security exceptions if you try this from the web...), and to
NetUtil.newChannel, etc. etc. - it's not clear to me why it'd be a
problem to use those to load the source code.
Barring any mistake, some of our network stack is written in JS. @zb, do
you see any way to untangle this?
This would only be a problem if you needed the JS-y bits of the network
stack to load those JS modules or components, which I don't think is the
case - that would surely also cause problems if it was the case with
Cu.import. Maybe I'm misunderstanding what problem you're trying to
identify?
~ Gijs
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
