<html><head>
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
</head><body style="color: rgb(0, 0, 0); background-color: rgb(255, 255,
255);" bgcolor="#FFFFFF" text="#000000"><br>
<blockquote style="border: 0px none;"
cite="mid:CAKBxTcKUK9WoVAgR67hCR8xVWNG27jegNCex7KV1uv1dK8pCqw@mail.gmail.com"
type="cite"><div style="margin:30px 25px 10px 25px;" class="__pbConvHr">
<div style="width:100%;border-top:2px solid
#EDF1F4;padding-top:10px;">
<div
style="display:inline-block;white-space:nowrap;vertical-align:middle;width:49%;"><a
moz-do-not-send="true" href="mailto:bobbyholley@gmail.com"
style="color:#485664
!important;padding-right:6px;font-weight:500;text-decoration:none
!important;">Bobby Holley</a></div>
<div
style="display:inline-block;white-space:nowrap;vertical-align:middle;width:48%;text-align:
right;"> <font color="#909AA4"><span style="padding-left:6px">2018
March 12 at 12:25</span></font></div> </div>
</div></blockquote>
<blockquote style="border: 0px none;"
cite="mid:CAKBxTcKUK9WoVAgR67hCR8xVWNG27jegNCex7KV1uv1dK8pCqw@mail.gmail.com"
type="cite">
<div style="color: rgb(144, 154, 164); margin-left: 24px;
margin-right: 24px;" __pbrmquotes="true" class="__pbConvBody">
<pre wrap="">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.</pre>
</div>
</blockquote>
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.<br>
<br>
<blockquote style="border: 0px none;"
cite="mid:CAKBxTcKUK9WoVAgR67hCR8xVWNG27jegNCex7KV1uv1dK8pCqw@mail.gmail.com"
type="cite"><div style="color: rgb(144, 154, 164); margin-left: 24px;
margin-right: 24px;" __pbrmquotes="true" class="__pbConvBody">
<pre wrap="">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.</pre></div></blockquote>
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?<br>
<br>
<blockquote style="border: 0px none;"
cite="mid:CAKBxTcKUK9WoVAgR67hCR8xVWNG27jegNCex7KV1uv1dK8pCqw@mail.gmail.com"
type="cite">
<div style="color: rgb(144, 154, 164); margin-left: 24px;
margin-right: 24px;" __pbrmquotes="true" class="__pbConvBody">
<pre wrap="">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.</pre>
</div>
</blockquote>
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.<br>
<br>
<blockquote style="border: 0px none;"
cite="mid:CAKBxTcKUK9WoVAgR67hCR8xVWNG27jegNCex7KV1uv1dK8pCqw@mail.gmail.com"
type="cite">
<div style="color: rgb(144, 154, 164); margin-left: 24px;
margin-right: 24px;" __pbrmquotes="true" class="__pbConvBody">
<pre wrap="">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.</pre>
</div>
</blockquote>
There are quite a few of these, if this search is accurate:<br>
<br>
<a class="moz-txt-link-freetext" href="https://searchfox.org/mozilla-central/search?q=component.*%5C.js&case=false®exp=true&path=*.manifest">https://searchfox.org/mozilla-central/search?q=component.*%5C.js&case=false®exp=true&path=*.manifest</a><br>
<br>
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.<br>
<br>
<blockquote style="border: 0px none;"
cite="mid:CAKBxTcKUK9WoVAgR67hCR8xVWNG27jegNCex7KV1uv1dK8pCqw@mail.gmail.com"
type="cite">
<div style="color: rgb(144, 154, 164); margin-left: 24px;
margin-right: 24px;" __pbrmquotes="true" class="__pbConvBody">
<pre wrap="">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.</pre>
</div>
</blockquote>
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.<br>
<br>
-myk<br>
<br>
</body></html>