On Mon, Mar 12, 2018 at 11:56 AM, Myk Melez <m...@mykzilla.org> wrote:
> Nicholas Nethercote <n.netherc...@gmail.com> > 2018 March 9 at 20:02 > > What's your definition of XPCOM? > > This is basically what I'm asking Kris. I define it as the system that > Firefox uses to make intra- and inter-language calls between C++ and JS via > XPIDL and XPConnect. > 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'm interested in what else it provides that makes it so indispensable. > > Indeed, but that doesn't tell me how much of XPCOM would remain essential > to Firefox if we no longer used XPIDL. > I think a better framing of your question would be "what could we remove if we removed XPIDL/XPConnect". 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. 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. > For example, XPCOM supports component registration and overriding at > runtime. But it isn't clear that Firefox needs those features, now that it > no longer supports XUL extensions (unless perhaps for system extensions). > 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. Getting rid of contract-ids entirely would entail some light modification of XPConnect to provide a different way to instantiate platform objects from JS, but the lion's share of the work would be fixing all the code that's set up to work with the existing mechanism. > > And xpcom/ contains a ton of stuff, as you say. But it isn't clear how > much of it is core to XPCOM and how much just happens to live in that > directory. > > I'm not playing the devil's advocate. I'm genuinely curious about the > extent of XPCOM's feature set (and how well it aligns with Firefox's > current requirements). > 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. > > -myk > > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
