Bobby Holley <mailto:bobbyhol...@gmail.com>
2018 March 12 at 12:25
That's not how I'd define XPCOM - XPCOM existed before XPIDL/XPConnect (and
the name XPConnect means "connecting Javascript to XPCOM"). But quibbling
over the definition isn't really useful.
I was aware that XPCOM predated XPConnect (although I didn't realize
that it predated XPIDL). Regardless, I agree that quibbling over the
definition isn't useful. However, it's useful to understand our
respective definitions, so we know what we're each talking about.
The main platform feature that XPConnect relies upon is the interface
inheritance hierarchy derived from nsISupports, including the
QueryInterface method to bounce between them. Specifically, objects must
implement an interface in that hierarchy to be reflected out-of-the-box by
XPConnect. However, there are lots of bits of C++ code that use
QueryInterface as well, which would be more work to change.
Do any of those bits of C++ code depend on a particular feature of
XPCOM, or do they just happen to use it to access components whose
interfaces would just as effectively (modulo the work required to
convert them) be exposed as concrete native classes?
The nsISupports hierarchy doesn't really cost us anything per se, certainly
not enough to justify the gargantuan task of trying to rip it out. Using it
heavily for performance-critical things can be slow (virtual methods plus
any QI overhead), but we should just fix those callsites when they come up.
There's also a developer ergonomics issue, as Components/QueryInterface
is more complex and cumbersome than other JS interfaces to native code
(WebIDL, Node.js Addons, etc.). We've worked around that to some extent
with Services.jsm and other hacks.
XPConnect's dependency on runtime component registration is limited to the
platform objects we've implemented in JS. If we get rid of those, that
dependency goes away.
There are quite a few of these, if this search is accurate:
https://searchfox.org/mozilla-central/search?q=component.*%5C.js&case=false®exp=true&path=*.manifest
And some of them depend on JSMs. Although it isn't clear at first glance
how significant those dependencies are, nor how much work it would be to
replace them with C++ or Rust implementations.
XPCOM is a not-very-well-delineated hodgepodge of mostly-independent
things. We are free to modify or remove any pieces that are causing
problems, provided someone can demonstrate that it's worthwhile.
Worthiness is relative to both effort and timeframe. That is to say: if
something would take a lot of work but would pay off in the long run,
then it may be worth a long-term (1-3 year) project for a small number
of engineers, even if it isn't worth a short-term effort that diverts a
large number of them.
-myk
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
