Re: So, what's the point of Cu.import, these days?

On Wed, Sep 28, 2016 at 1:19 AM, David Teller wrote: > > * CommonJS > ​Just a heads up: the devtools have been using CommonJS modules and lazily requiring modules for a couple years now. If you don't want to jump directly to ES modules, reusing our infrastructure is

Re: So, what's the point of Cu.import, these days?

On Tuesday, September 27, 2016 at 2:01:09 PM UTC-7, David Teller wrote: > "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) { >

Re: So, what's the point of Cu.import, these days?

\o/, let's join forces :) I admit that I haven't thought at all about the impact on exceptions. If we migrate to ES6 modules, then the problem is something that we don't need to handle. If we migrate to CommonJS modules with a loader built into XPConnect, I think that we can solve this without

Re: So, what's the point of Cu.import, these days?

On Sun, Sep 25, 2016 at 12:13:41AM +0200, David Teller wrote: So, can anybody think of good reason to not do this? One major problem I see with this is that we currently lazily import most modules the first time that a symbol they export is referenced. If we move to CommonJS or ES6 modules,

Re: So, what's the point of Cu.import, these days?

I have posted a draft of a plan for migrating from JSM to ES6 modules here: https://gist.github.com/Yoric/2a7c8395377c7187ebf02219980b6f4d Cheers, David ___ dev-platform mailing list dev-platform@lists.mozilla.org

Re: So, what's the point of Cu.import, these days?

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

Re: So, what's the point of Cu.import, these days?

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,

Re: So, what's the point of Cu.import, these days?

You are right, I wrote RequireJS but I was thinking CommonJS, much as is used currently in DevTools and Jetpack. According to their documentation, Facebook's Flow analysis already supports CommonJS modules [1]. Of course, they prefer ES6 modules. It just remains to be seen whether we can migrate

Re: So, what's the point of Cu.import, these days?

Le mardi 27 septembre 2016 14:49:36 UTC+2, David Teller a écrit : > I have opened bug 1305669 with one possible strategy for migrating > towards RequireJS. RequireJS [1] is a peculiar choice for chrome code especially if your goal is static analysis. From this thread and what I read in bug, it

Re: So, what's the point of Cu.import, these days?

On 27/09/16 11:58, Gijs Kruitbosch wrote: > On 27/09/2016 10:28, David Teller wrote: >> 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

Re: So, what's the point of Cu.import, these days?

I have opened bug 1305669 with one possible strategy for migrating towards RequireJS. Cheers, David On 25/09/16 01:16, Bobby Holley wrote: > If the conversion is tractable and we end up with module ergonomics that > frontend developers are happy with, I'm certainly in favor of this from > the

Re: So, what's the point of Cu.import, these days?

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

Re: So, what's the point of Cu.import, these days?

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

Re: So, what's the point of Cu.import, these days?

On Mon, Sep 26, 2016 at 12:33 PM, wrote: > ES6 modules are supported for chrome code, but not yet for content (pending > spec related discussions that are not relevant for chrome). Can someone please publicly log this issue at https://github.com/whatwg/html or wherever

Re: So, what's the point of Cu.import, these days?

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. 2) Conditional vs. static Cu.import allows us to decide *when*

Re: So, what's the point of Cu.import, these days?

I agree that my formulation was poor, but that's what I meant: in *a single webpage*, all these modules behave the same wrt the underlying objects. On 26/09/16 18:14, Boris Zbarsky wrote: > On 9/26/16 12:09 PM, David Teller wrote: >> In web content, that's also the case with ES6 and

Re: So, what's the point of Cu.import, these days?

On 9/26/16 12:09 PM, David Teller wrote: In web content, that's also the case with ES6 and require-style modules. No, only on a per-global basis. Put another way, if you Cu.import the same thing from two instances of browser.xul, you will get the same objects. But if import the same ES7

Re: So, what's the point of Cu.import, these days?

In web content, that's also the case with ES6 and require-style modules. I realize that it's a bit more complicated in chrome code, with all the XUL + XBL + XPCOM + subscript loader, but I believe that we should be able to reach the same result. Cheers, David On 26/09/16 18:01, Joshua Cranmer 

Re: So, what's the point of Cu.import, these days?

On 9/24/2016 5:13 PM, David Teller wrote: Which begs the question: what's the point of `Cu.import` these days? One major difference between Cu.import and ES6/require-style modules is that only one version of the script is created with Cu.import. This allows you to make databases using

Re: So, what's the point of Cu.import, these days?

Ideally, it would be great to replace our current messy module loading with something stricter. I suspect, however, that we have subtleties that won't let us proceed. Let me detail a bit some of the problems that might occur if we wish to rewrite existing code with a stricter module loader. *

Re: So, what's the point of Cu.import, these days?

On Sunday, 25 September 2016 07:32:32 UTC+1, David Teller wrote: > What's the current status of the implementation of ES6 modules? ES6 modules are supported for chrome code, but not yet for content (pending spec related discussions that are not relevant for chrome). It would be great if we

Re: So, what's the point of Cu.import, these days?

If I understand correctly es module imports work differently from JSM's Cu.import in which scope they operate in. JSM's are singletons, while importing in es imports code into your JS context. How would you want to differentiate between those two modes? Other things in the es import is that

Re: So, what's the point of Cu.import, these days?

What's the current status of the implementation of ES6 modules? Also, to use them in chrome code, can we support synchronous loading? Or would we need to make the rewrite more complicated to support asynchronous loading? On 25/09/16 02:35, Bill McCloskey wrote: > If we're going to do a mass

Re: So, what's the point of Cu.import, these days?

If we're going to do a mass conversion, shouldn't we try to move to ES modules? There's some support for them in SpiderMonkey for chrome code, and it would be great to move towards a future standard. -Bill On Sat, Sep 24, 2016 at 4:16 PM, Bobby Holley wrote: > If the

Re: So, what's the point of Cu.import, these days?

If the conversion is tractable and we end up with module ergonomics that frontend developers are happy with, I'm certainly in favor of this from the platform side. It would get us the 15-20MB of memory savings that bug 1186409 was pursuing without the smoke and mirrors. bholley On Sat, Sep 24,

So, what's the point of Cu.import, these days?

Once again, there have been discussions on the feasibility of adding static analysis to our JS code, possibly as part of MozReview. As usual, one of the main problems is that we are not using standard JS, so we pretty much cannot use standard tools. One of the main differences between