In my XPCOM Cheat Sheet (which I really should look at updating), I wrote:
As a rule of thumb, use XPIDL-based arrays for arrays of a single
primitive type, in or out (not inout). For anything else, use nsIArray or
Unfortunately, that doesn’t work with native string types like DOMString:
interface nsIFooArray : nsISupports
void setArray(in PRUint32 count,
in DOMString strings);
Error: [domstring], [utf8string], [cstring], [astring] types cannot be used in array parameters
To which I say, “Well, that sucks.” Read on in the extended entry for more details.
Continue reading Arrays of strings in XPCOM
I had planned to write an article on ECMAScript Harmony and my ideas for corresponding XPIDL changes… but four months after its announcement, I find I still don’t know what’s in the Harmony spec! (We know a few things that are out… but since the initial blog surge, it’s been quiet.)
So I’ve decided to put my ideas for XPIDL on the side, and move on to the last part in this series: my attempt at creating a XPCOM component for two-dimensional arrays. Read on for further details.
Continue reading Back to Basics: Two-Dimensional Arrays
A year or so ago, I introduced the
module to Verbosio, and tried to get it into mozilla.org code. The idea
arrays, XPCOM arrays,
nsIArray objects and
objects. Although it did not get in, I’ve been rethinking half of the
ArrayConverter module’s functionality, and I believe now that I
I planned on writing two different articles – one talking about
reinventing the wheel unnecessarily, and another talking about why I, a
out, though, that each of these has roughly the same answer: the penalties of
XPConnect. Read on for
Continue reading Back to Basics: Why write components in C++?
(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 –
is one of the more complex ones from a C++ standpoint. In particular, they
provide arrays through the
interface, object containers through
and a bunch of primitive values such as strings and floating-point numbers
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 (
You’ll find an exception to the rule in
that’s about it.
In this article, I’ll talk about two approaches to this problem – and the
choice I made.
Continue reading Back to Basics: Read-only Data
I realized that for Verbosio, I have forgotten to explicitly add the MPL/GPL/LGPL tri-license boilerplate to a number of my files. Although the project is open-source and under these licenses, I still see the missing boilerplates as an oversight.
I did a quick Google search for Perl scripts to find these files, and found only this: an Add_License script. It does support MPL, but not the tri-license.
Does anyone out there have a script for identifying these files? I’d prefer to add the boilerplates myself, but I still need to search for where they are not.
Once upon a time, I asked a question in the #developers channel
How do I define that a XPCOM component is
actually a service?
The answer I received:
See if the caller uses do_GetService(), or
This is less than satisfactory. I should be able to say “There can be only
one” and not “Oh, please, don’t create more than one of me.” Over the years,
the standard way to do it for C++-based XPCOM components. Read on in the
extended entry for details.
Continue reading Back to Basics: Defining XPCOM Services
With XPIDL, XPCOM components can be very strict about what they allow.
Simply put, if you try to pass in an argument to a XPCOM component, and the
component requires a type that your argument doesn’t support, it won’t work.
exceptions. This is a good thing.
Many of the basic data structures – nsIArray, nsIPropertyBag, etc. – take
nsISupports argument. This covers most objects you construct
and work with. This is all well and good… unless you want to pass in a raw
type such as a number, a
false value, a
string, etc. Then you’re stuck.
Fortunately, all is not lost. There is an interface named
nsIWritableVariant, which XPCOM provides for wrapping native
types in an
nsISupports object. (There are type-specific
nsISupportsPRBool as well, but
nsIWritableVariant is an one-size-fits-all solution.) Even more
interesting, its read-only companion,
nsIVariant, is “magical”
nsIVariant turns the strengths of XPIDL barriers so
that they are no longer fighting you, but working with you. This is what I am
calling judo with
nsIVariant. Read on in the extended entry for more details.
Continue reading Back to Basics: Judo with nsIVariant
A couple weeks ago, I started reading “Learning Python”, by
Mark Lutz. It’s an interesting feeling, going back to the basics of
programming – numbers, strings, arrays, etc. In reading this book, I kept
thinking there were some things missing from the basic XPCOM tool set.
Therefore, I decided to attempt implementing these missing pieces.
Now, I could be totally wrong about any or all of these being missing…
but it’s also a good exercise for me to push my boundaries and strengthen my
C++ skill set. The result is not only code that I can use for
proof-of-concept, but code that may be useful elsewhere.
This is the first article in a multipart series titled “Back to Basics”,
exploring these concepts. This first article is about native C++ arrays
through XPCOM – and making sure I don’t leak memory. Read on in the extended
entry for details.
Continue reading Back to Basics: XPCOM Arrays and Memory
Original video and YouTube
Yeah, that’s me. You’d think I’d burned through my fifteen minutes of fame already…
Yes, I wore the Mozilla shirt deliberately. My role at Skyfire is to basically customize Mozilla Firefox for our needs. So it seemed fitting to combine the shirt and the little Skyfire badge.
As for the dancing itself… I think I can hold my own. 🙂 I’ll say this much – at that level, it is a workout in addition to a whole lot of fun. I don’t care about being alone out there either. I basically make it up on the spot (or I used to, anyway…)