You are currently viewing a snapshot of www.mozilla.org taken on April 21, 2008. Most of this content is highly out of date (some pages haven't been updated since the project began in 1998) and exists for historical purposes only. If there are any pages on this archive site that you think should be added back to www.mozilla.org, please file a bug.
There's been a lot of confusion about this slide from people who didn't actually hear my presentation. Taken out of context, the last item on this slide apparently makes people think I'm unreservedly damning XPCOM. This isn't the case. As I hope I made clear in the talk itself, and now must make clear to everyone else: In any engineering task, decisions are made by measuring the cost and the benefit of each of the alternatives to the best of our ability, and picking the most profitable route by those standards.
We have some great and useful technologies in mozilla. Among them, XPConnect, which is very closely tied with XPCOM. XPCOM use has a high cost, including forcing a particular memory management model on a large set of classes which might otherwise function equally well in many different settings; significantly decreasing the amount of code the compiler can inline; virtualizing almost every function call; and limiting the use of otherwise potentially beneficial C++ facilities, such as exceptions, virtual base classes, and templates. There are specific cases where XPCOM also yields great benefits, particularly in combination with XPConnect: run-time replaceable implementations which may have been built with any compiler; and integrated scriptable interfaces on XPCOM classes.
We pay this high cost of XPCOM for a great many classes in mozilla. However, we can exploit the benefit of replaceable implementations in only a select few cases. While scriptability is key to almost every system above this level, scriptability in and of itself would not necessarily have required this cost so broadly across the code base.
XPCOM has proved to be very useful to and in mozilla; but there is debate over whether the cost has outweighed the benefit as we use it today. It is my opinion that within mozilla, we have too zealously exploited XPCOM, and artificially componentized our design to too granular a level. As you are working on mozilla, or your own project which uses XPCOM and XPConnect, my advice is to carefully consider each potential use of this technology. Build scriptable interfaces where it makes sense. In the end, you will not need every single class to be scriptable, nor can your implementation realisticly expect every class to be runtime replaceable. Exploit profitable facilities of C++ where they make sense for you, and when they conflict with your use of XPCOM, e.g., exceptions, appropriately contain them at your XPCOM boundaries.