This is a followup to bug 166147. If we make NS_IMPL_OWNINGTHREAD (the debug code for our threadsafety warnings) based on a class with a constructor, we can make NS_IMPL_ISUPPORTS unnecessary and just remove it.

This isn't tested yet, since my build is only part of the way through.

I've tested that the assertions still work by removing some "THREADSAFE_" in places that need it in my tree, and seeing that assertions do fire. Also, in comment 0, I meant NS_INIT_ISUPPORTS rather than NS_IMPL_ISUPPORTS.

Comment on attachment 102723 [details] [diff] [review] patch I am not sure that we should mark NS_INIT_ISUPPORTS deprecated or suggest that developers not use this macro. This reason, although minor, is that it allows us to hook into xpcom object constructors quite easily. For example, a bloat too could redefine this macro to do something. Thoughts?

Anybody else who wants to hook in can just use the same method that this uses and that the refcount uses (bug 166147) -- hook in via NS_DECL_ISUPPORTS and a class with a constructor (and if they don't want to take up space, they could use one of the two existing constructors created by this bug and bug 166147 -- one is used always and the other is #ifdef DEBUG). (Am I the only one who finds NS_INIT_ISUPPORTS() somewhat ugly in a C++ world, where member initializers are preferred to assigments in the constructor? I also usually forget it when I'm implementing nsISupports.)

if there is another way, great. After thinking about this for a bit, the DECL macro could probably do everything we need. Before you land this, please post an announcement to the xpcom ng.

Comment on attachment 102723 [details] [diff] [review] patch nice! sr=alecf

GetThread should probably be a const function.

Fix checked in to trunk, 2002-11-06 05:09 PDT, with bbaetz's comment addressed by adding |const|. I filed bug 178643 on eventually removing the uses of NS_INIT_ISUPPORTS from the tree.

Yay!

*** Bug 172845 has been marked as a duplicate of this bug. ***