I'd like to make |NS_INIT_ISUPPORTS| empty and deprecate it. A patch to
do this is in http://bugzilla.mozilla.org/show_bug.cgi?id=174225 .
Historically, |NS_INIT_ISUPPORTS| and its old synonym, |NS_INIT_REFCNT|,
have done two things:
1. Initialize |mRefCnt| to 0.
2. In |DEBUG| builds, initialize |_mOwningThread| to the current
thread for the threadsafety assertions in the code generated by
|NS_IMPL_ADDREF| and |NS_IMPL_RELEASE|.
In bug 166147, alecf removed (1) by making |mRefCnt| into an
|nsAutoRefCnt| that auto-initializes itself to 0. My patch in (2) does
a similar trick for |_mOwningThread| (which is very easy since there's
no manual manipulation of |_mOwningThread|). This leaves
|NS_INIT_ISUPPORTS| empty.
The only reason to do this is if we want to eliminate (i.e, not require)
|NS_INIT_ISUPPORTS|, since if it's empty, people will start forgetting
it and not seeing any threadsafety assertions because of their error. I
want to eliminate it because:
* It's one more thing to remember to do when implementing |nsISupports|
(and I've forgotten it many times).
* It's somewhat ugly from a C++ perspective, where
member-initialization is preferred to assignment in constructors.
I don't think there's a significant cost to not requiring it because
anything that can be done using the macro can be done in the constructor
of an object that is declared in |NS_DECL_ISUPPORTS|. After this patch,
we'll already have one such object that's present all the time and
another that's present only in |DEBUG| builds, and if someone really
needs to hack something in based on some other condition that doesn't
require any storage, it can always go in the constructor of
|nsAutoRefCnt| in some |#ifdef|.
Does this seem reasonable? Any objections?
-David
--
L. David Baron <URL: http://www.people.fas.harvard.edu/~dbaron/ >
