On Fri, Feb 02, 2018 at 10:25:17AM +0100, Marco Bonardo wrote:
Hi Kris, this change is awesome.
Is it ok to continue use defineLazyModuleGetters (plural), since it
internally now uses chromeUtils.defineModuleGetter? Any downsides?
It's probably fine for now.
There is a downside, though, when you call it from outside a JSM or
component. In that case, XPCOMUtils.jsm gets a cross-compartment wrapper
for the object you're defining the getters on, which means the getter
property itself is defined on the original object as a cross-compartment
wrapper, and the whole process requires jumping back and forth across
compartment boundaries several times.
That was one of the reasons XPCOMUtils.defineLazyModuleGetter was
expensive to begin with. And it's possible that the extra overhead of
that outweighs the better JIT optimization of the loop. I won't be sure
until I have time to profile.
On Fri, Feb 2, 2018 at 7:48 AM, Ed Lee <edi...@mozilla.com> wrote:
Great to see these types of broad changes getting wins, so if there's
a good way to keep up to date and ahead of these types of incoming
changes, that would be great. I learned of these changes from this
week's biweekly Firefox meeting the morning that they were already
inbound. Activity Stream is still in the process of getting automation
passing with these changes, but I don't think we should over-rotate as
this is a pretty unique type of change to our special development
process.
On Thu, Feb 1, 2018 at 10:01 PM, Kris Maglione <kmagli...@mozilla.com> wrote:
a new ESLint rule has been added to prevent new instances.
In particular, eslint-plugin-mozilla required changes to support this
new way of adding globals, and Standard8 was able to publish the new
version within a day of the changes breaking
outside-of-mozilla-central repositories that were touched by the
automatic rewrite and have dependencies on the plugin. I believe for
this particular change, the eslint-plugin-mozilla additions could have
been published sooner (except for the part of turning the rule on by
default).
Separate from that, Activity Stream has JSMs that get converted to
commonjs for testing and esmodules for building (as an intermediary
step to combine and optimize with our other esmodules for export to
mozilla-central). These particular changes broke our tooling to do
those conversions, but it's relatively straightforward to fix up. As I
mentioned earlier, probably nothing really major to change in terms of
process because of this, so mostly just making a note of this as a
potential type of breakage that could happen again in the future.
Ed Lee
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
