Burning Chrome

Back to Basics: Why write components in C++?

A year or so ago, I introduced the ArrayConverter module to Verbosio, and tried to get it into mozilla.org code. The idea was simple: a JavaScript library for converting between native JavaScript arrays, XPCOM arrays, nsIArray objects and nsISimpleEnumerator objects. Although it did not get in, I've been rethinking half of the ArrayConverter module's functionality, and I believe now that I overlooked something.

I planned on writing two different articles - one talking about reinventing the wheel unnecessarily, and another talking about why I, a JavaScript expert, would choose to write XPCOM components in C++. It turns out, though, that each of these has roughly the same answer: the penalties of XPConnect. Read on for further details.

Back to Basics: Read-only Data

(I'm posting two articles today - and for those of you who correctly pointed out my XPCOM Services article had bugs in the sample code, I've updated it to point to live code with a couple adjustments. I continue to welcome your insight.)

XPCOM provides a lot of basic data types - nsIVariant is one of the more complex ones from a C++ standpoint. In particular, they provide arrays through the nsIArray interface, object containers through nsIPropertyBag and nsIPropertyBag2, and a bunch of primitive values such as strings and floating-point numbers through nsISupportsPrimitives. XPCOM also provides components and contracts for these data types in C++, so you don't have to reimplement them. (You can if you want to, but it's usually not necessary, as I'll explain in another article.)

There's only one downside to these basic components: they're eternally changeable. What that means is I can pass a nsISupportsString to your component, and it can change that value before sending it onto another component. From my perspective, I don't have any way of "sealing" the data, of making it read-only. Even if I pass you one of these components in an interface that has no change methods (nsIArray), you could easily QueryInterface it for an interface that has change methods (nsIMutableArray). You'll find an exception to the rule in nsIWritableVariant, but that's about it.

In this article, I'll talk about two approaches to this problem - and the choice I made.