extending mailnews objects

Kent James kent at caspia.com
Mon Jun 7 23:06:36 UTC 2010

  In my work to prepare a new account type for mailnews code as an 
extension (see http://mesquilla.com/category/exchange-web-services-ews/) 
, I end up extending many base objects like nsMsgDBFolder, 
nsMsgIncomingServer, and nsMsgMailNewsUrl. In C++, I started out just 
creating new classes that inherit from those classes, as is commonly 
done in existing mailnews code. Rather than using inheritance, I see 
that a lot of mozilla code forwards properties to objects loaded through 
XPCOM using NS_FORWARD macros.

My question is this: Is there any strong reason to prefer one over the 
other? And if forwarding makes sense, could I have a general agreement 
that patches would be accepted in comm-central that allowed creation of 
XPCOM objects that implemented the base objects?

As a specific example, I ran into some problems using inheritance with 
the nsMsgDatabase extension, because I ended up with multiple copies of 
static variables defined in the base file. I solved that problem by 
switching to forwarding. I also believe that my extension DLL files end 
up with their own copies of the object code for the base classes, which 
seems to bother me (and was the root of my nsMsgDatabase problem). But 
perhaps that is just a linking issue?

The changes would involve modifying any of the base classes to replace 
pure virtual non-XPCOM functions in the base class with XPCOM versions, 
making sure that all XPCOM methods are defined (as NOT_IMPLEMENTED if 
needed), and creating components so that the XPCOM base objects can be 

I'm not sure how this affects people trying to do this through js. It 
seems like it would help them even more than my C++ approach, but 
jcranmer does not agree with that for some reason.


More information about the tb-planning mailing list