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)
Core
XPCOM
Tracking
()
RESOLVED
FIXED
mozilla1.8beta1
People
(Reporter: benjamin, Assigned: darin.moz)
References
Details
Attachments
(2 files)
42.93 KB,
patch
|
benjamin
:
review+
dbaron
:
superreview+
|
Details | Diff | Splinter Review |
4.56 KB,
patch
|
Details | Diff | Splinter Review |
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
Assignee | ||
Comment 1•20 years ago
|
||
-> me, i've got a patch brewing for this.
Assignee: bsmedberg → darin
Assignee | ||
Updated•20 years ago
|
Severity: normal → minor
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.8beta
Assignee | ||
Comment 2•20 years ago
|
||
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.
Assignee | ||
Comment 3•20 years ago
|
||
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.
Assignee | ||
Updated•20 years ago
|
Attachment #165176 -
Flags: review?(bsmedberg)
Reporter | ||
Updated•20 years ago
|
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...
Assignee | ||
Comment 5•20 years ago
|
||
/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.
Assignee | ||
Comment 7•20 years ago
|
||
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.
Assignee | ||
Comment 9•20 years ago
|
||
> 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).
Assignee | ||
Comment 10•20 years ago
|
||
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+
Comment 12•20 years ago
|
||
(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.
Comment 13•20 years ago
|
||
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.
Assignee | ||
Comment 15•20 years ago
|
||
fixed-on-trunk
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Comment 16•20 years ago
|
||
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 → ---
Assignee | ||
Comment 17•20 years ago
|
||
fixed checked in for MingW / GCC 3.4 bustage.
Status: REOPENED → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → FIXED
Comment 18•20 years ago
|
||
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.
Description
•