Closed Bug 263360 Opened 20 years ago Closed 20 years ago

Make CallCreateInstance use NS_GetComponentManager instead of nonfrozen/deprecated nsComponentManager symbols

Categories

(Core :: XPCOM, defect)

defect
Not set
minor

Tracking

()

RESOLVED FIXED
mozilla1.8beta1

People

(Reporter: benjamin, Assigned: darin.moz)

References

Details

Attachments

(2 files)

CallCreateInstance uses non-frozen/deprecated nsComponentManager symbols. Let's
make it use NS_GetComponentManager instead. Followup to
https://bugzilla.mozilla.org/show_bug.cgi?id=237745#c34
Blocks: 267040
-> me, i've got a patch brewing for this.
Assignee: bsmedberg → darin
Severity: normal → minor
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.8beta
Attached patch v1 patchSplinter Review
This patch replaces the remaining nsComponentManager:: methods with new
versions of CallCreateInstance and CallGetClassObject.	 When
MOZILLA_STRICT_API is defined, I implement them using NS_GetComponentManager,
but when it is not defined, I implement them using direct calls to
nsComponentManagerImpl::
gComponentManager.
Since I moved nsComponentManagerUtils.h into xpcom/glue, I thought I'd include
a diff of it against its old location in xpcom/components.  The changes to the
header file were minor.  I might ask myk or someone to move the CVS file when
it comes time to check this in.
Attachment #165176 - Flags: review?(bsmedberg)
Attachment #165176 - Flags: review?(bsmedberg) → review+
Hopefully overloading the same name as both a function and a function template
won't confuse any of the compilers...
/sigh/ ... i really hope that isn't a problem.  but still... do you think i
should name the functions like NS_CreateInstance instead of CallCreateInstance,
etc.?
Or perhaps CallCreateInstanceImpl or something else that discourages people from
calling them directly.
I actually meant for these to be called directly.  Afterall, why not?  For our
internal code, it makes sense to have direct function calls for the component
manager methods.  There are few places where we need to explicitly pass an IID
parameter (e.g., in XPConnect), and in those cases it might be nice to avoid
calling NS_GetComponentManager.
Those are quite rare, though, so they can deal with an ugly name and the few
people who deal with that code will know it's ok.
Blocks: 268520
Blocks: 239088
No longer blocks: 268520
> Those are quite rare, though, so they can deal with an ugly name and the few
> people who deal with that code will know it's ok.

Why is an ugly name better?  That's what I don't get.  Why don't we want to make
the full CreateInstance easy to call?  I'm definitely against having direct
callers to something named CallCreateInstanceImpl.  I'll stick with
CallCreateInstance, and I'll change it only if it causes problems for some
compiler (which I really doubt).
Comment on attachment 165176 [details] [diff] [review]
v1 patch

dbaron: can you please sr this patch.

please note that i intend to move nsComponentManagerUtils.h from
xpcom/components into xpcom/glue.
Attachment #165176 - Flags: superreview?(dbaron)
Comment on attachment 165176 [details] [diff] [review]
v1 patch

sr=dbaron.  I guess we'll see if removing some of those null checks causes any
problems.
Attachment #165176 - Flags: superreview?(dbaron) → superreview+
(In reply to comment #10)

> please note that i intend to move nsComponentManagerUtils.h from
> xpcom/components into xpcom/glue.

Move completed.  You'll need to 'cvs remove' the file from the old location as
part of your checkin.
some how this seems to have broken the aviary 1.0 branch and the mozilla 1.7 branch:

http://tinderbox.mozilla.org/showbuilds.cgi?tree=Aviary-1.0

justdave should the cvs move have been moving files on branch tags? Brian just
cc'ed you on my e-mail thread where I've been trying to figure out why the
branches aren't building. 
I think the tag removal was done on the wrong file: nsComponentManagerUtils.cpp,
instead of the copied nsComponentManagerUtils.h.  We need to get the tags recovered.
fixed-on-trunk
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
This checkin causes the following on my Win32/MinGW/cygwin build :-

In file included from e:/mozilla/source/thunderbird/mozilla/xpcom/glue/nsCompone
ntManagerUtils.cpp:46:
e:/mozilla/source/thunderbird/mozilla/xpcom/glue/nsComponentManagerUtils.h: In f
unction `nsresult CallCreateInstance(nsIFactory*, nsISupports*, DestinationType*
*)':
e:/mozilla/source/thunderbird/mozilla/xpcom/glue/nsComponentManagerUtils.h:293:
error: invalid use of undefined type `struct nsIFactory'
e:/mozilla/source/thunderbird/mozilla/xpcom/glue/nsComponentManagerUtils.h:49: e
rror: forward declaration of `struct nsIFactory'
e:/mozilla/source/thunderbird/mozilla/xpcom/glue/nsComponentManagerUtils.h: In f
unction `nsresult CallCreateInstance(nsIFactory*, DestinationType**)':
e:/mozilla/source/thunderbird/mozilla/xpcom/glue/nsComponentManagerUtils.h:307:
error: invalid use of undefined type `struct nsIFactory'
e:/mozilla/source/thunderbird/mozilla/xpcom/glue/nsComponentManagerUtils.h:49: e
rror: forward declaration of `struct nsIFactory'
make[4]: *** [nsComponentManagerUtils.o] Error 1
make[4]: Leaving directory `/cygdrive/e/mozilla/source/thunderbird/mozilla/xpcom
/glue'
make[3]: *** [libs] Error 2
make[3]: Leaving directory `/cygdrive/e/mozilla/source/thunderbird/mozilla/xpcom
'
make[2]: *** [libs] Error 2
make[2]: Leaving directory `/cygdrive/e/mozilla/source/thunderbird/mozilla'
make[1]: *** [alldep] Error 2
make[1]: Leaving directory `/cygdrive/e/mozilla/source/thunderbird/mozilla'
make: *** [alldep] Error 2
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
fixed checked in for MingW / GCC 3.4 bustage.
Status: REOPENED → RESOLVED
Closed: 20 years ago20 years ago
Resolution: --- → FIXED
Sorry for the delay in checking the fix. I had to deal with a major build config
change that apparantly landed at midday.

Anyway, the fix looks good.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: