On 3/26/18 6:29 PM, Myk Melez wrote:
Do any of those bits of C++ code depend on a particular feature of
XPCOM
They depend on the dynamic casting provided by QueryInterface.
That said, they could in many cases switch to other methods of dynamic
casting that are more limited...
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?
That happens as well.
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.).
Note that XPConnect did support other ways of exposing things like
constructors, at least on Window instances. Ways we recently removed,
because implementing the back end of such things was painful enough that
nothing except the DOM (broadly speaking, as in web-exposed stuff)
bothered to in practice, and the DOM is now on WebIDL.
We've worked around that to some extent with Services.jsm and other hacks.
I think we should think about other ways to address such pain points as
needed. Please file blockers for
https://bugzilla.mozilla.org/show_bug.cgi?id=1444515
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:
Yes, there are.
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.
I think we all agree on that. The devil is in the details. ;)
-Boris
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
