This is fantastic news.
XPIDL has been stagnant for far too long, given how core a part
of our platform it is. As anyone who's had to work with it can
attest, it's basically a relic of the coding styles of the late
'90s, and doesn't translate well to the practices of our current
codebase. And the frozen state of xptcall has long been part of
the problem.
I'm happy to see these things being modernized, with particular
thanks to Nika Layzell who's done the lion's share of that work
lately.
-Kris
On Tue, Jul 31, 2018 at 09:14:01AM -0700, Bobby Holley wrote:
XPConnect requires some platform-specific code to do its magic [1]. There
are around ~28 different copies of this code in xpcom/reflect/xptcall,
which makes it very difficult to maintain.
Historically, we've handled this by treating xptcall as fixed and working
around its deficiencies. Given the need to evolve our codebase, I don't
believe this is the right trade-off for us today.
Here's the plan going forward:
* Developers may make breaking changes to xptcall, provided they keep the
Tier-1 platforms on Treeherder green.
* Such changes should be marked as blocking bug 1479807 (xptcall-changes),
so that maintainers of Tier-3 platforms can easily follow along.
* Any xptcall implementation that didn't build and run at the time of the
most recent ESR release may be removed [2].
Please get in touch if you have any questions.
Cheers,
bholley
[1] Specifically, to dynamically invoke C++ virtual methods from JS, and to
allow JS objects to impersonate arbitrary XPCOM C++ objects.
[2] The source is, of course still available via version history if
somebody decides to support the platform again.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
