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

Reply via email to