On Tuesday, September 27, 2016 at 2:28:54 AM UTC-7, David Teller wrote:
> If I understand ES6 modules correctly, two imports from the same webpage
> will return the same module instance, right?
I don't think this is a correct statement across globals.
When you load two modules in one js context, maybe, but when you have two
browser.xul windows open and you load a JSM, it's shared between them.
> 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.
So this opens up an interesting can of worms.
As we move into multi-process world, would we be interested in making our
module loading code make it less impossible to chunk chrome into separate
processes?
> I *think* that we can get rid all instances of the former, but I also
> think that it's a multi-year project to do it all across our code.
I don't see how or why would we want to get rid of all instances of the former.
It seems to me that we use the nature of singletons quite a lot - for example,
I'm working on a replacement for chrome registry for l10n resources and I use
runtime global cache by just having a single cache object in my JSM.
> @zb, do you think that it would be possible to have a migration path
> from jsm towards ES6 modules that would let us do it one module at a
> time? Let's assume for the moment that we can rewrite `Cu.import` to
> somehow expose ES6 modules as jsm modules.
I don't see a reason why wouldn't it be possible. We could even start by just
promoting the new method for new code.
> Also, how would you envision add-ons (which could add some kind of
> modules dynamically) in a world of ES6 modules?
I linked to the ECMA proposals that give us nested/conditional imports.
I believe that we should go this route.
> It is my understanding that ES6 modules, being designed for the web,
> don't expect any kind of sync I/O, and "just" block `onload`.
> Transitioning to ES6 modules would undoubtedly require some hackery here
> to pause the calling C++ code.
Quite the opposite.
The first version of es6 modules is synchronous, even static, from the
perspective of the user.
Only the import() function proposal introduces async way to load modules.
I see a huge value in both so I'd be happy if we implemented both internally
and through this participated in the evolution of the import function proposal.
personal preference would be to not settle on the intermittent module loading
API. If we want to move, let's go all the way and do this right.
One idea that came to mind for how could we differentiate between singleton
loading and in-context loading using statements would be to differentiate by
path.
Not sure if it feels right or a dirty hack, but sth like this:
import { Registry } from 'resource://gre/modules/L10nRegistry.jsm';
would work like Cu.import,
import { Registry } from 'resource://gre/modules/my-file.js';
would load my-file in-context.
Does it sound like a cool way of solving it or a terrible way of complicating
it?
zb.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
