extending mailnews objects
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