On 27/09/16 19:35, Zibi Braniecki wrote:
> 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?
That's too many negations for my poor brain :)
I think that we want to keep the current behavior of
one-chrome-module-has-only-one-instance-per-JSRuntime. Anything else
will introduce impossible-to-track bugs. From what I read below in your
message, I believe that we agree.
>> 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.
"why": because you wrote "The former is a more tricky." in your previous
message. If it's not, I'm quite happy to not remove them :)
For reference, "the former" is a snippet such as:
if (needed) {
Cu.import(...);
}
to which I would add
function foo() {
Cu.import(...);
}
>
> 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.
For this, we need first to make sure that two distinct .jsm modules/.xul
files/whatever chrome stuff that can load a ES6 module will receive the
same object when loading the same url, right? This seems like a pretty
important first step.
>> 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.
Ok. I think that works, but we should check with the addons team.
>> 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'm talking of the perspective of the embedder (here, Gecko). Reading
the implementation of ES6 modules, I have the impression that loading is
sync from the perspective of the JS & DOM but async from the perspective
of the embedder. Am I wrong?
If so, I fear that we're going to end up in gotcha cases whenever C++
calls JS code.
> 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.
Well, my personal preference is whatever doesn't require us to rewrite
the entire codebase of Firefox :)
>
> 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?
I think it complicates stuff. Among other things, we have code that's
designed to be loaded both as a jsm and as a CommonJS module, and I'm
pretty sure that this would break all sorts of havoc.
Cheers,
David
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
