Interface headers contain implementation

RESOLVED FIXED in mozilla1.0

Status

()

P3
normal
RESOLVED FIXED
19 years ago
17 years ago

People

(Reporter: jeff.dyer, Assigned: dougt)

Tracking

({helpwanted})

Trunk
mozilla1.0
x86
All
helpwanted
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: nsbeta3)

Attachments

(1 attachment)

(Reporter)

Description

19 years ago
nsIServiceManager.h and nsIComponentManager.h contains implementation code that 
makes inclusion into external component code (e.g. Java Plugin) problematic.
(Reporter)

Comment 1

19 years ago
I've assigned it to myself for further investigation. CC'ing Stanley.
(Reporter)

Comment 2

19 years ago
Created attachment 6001 [details] [diff] [review]
Fix
(Reporter)

Comment 3

19 years ago
Plugins must include nsIServiceManager.h and nsIComponentManager.h to get the 
corresponding interface definitions. Unfortunately, these files contain 
non-interface definitions which depend on implementation code outside of the 
included headers. There are two obvious solutions: 1. for plugins to link in as 
much of mozilla as is necessary to resolve all the external references; and 2. 
the interface header files to be restructured to contain interface definitions, 
with concrete classes, etc. included separately. I have posted a patch that does 
basically this, but without moving any code. I've wrapped the code with 
implementation dependencies in #ifndef USE_PURE_COM_INTERFACES ... #endif 
statements so that plugins that want just the interfaces can get only them by 
adding the statement #define USE_PURE_COM_INTERFACES before relevant include 
statements.

I'm reassigning to the module owner for review.
Assignee: jeff.dyer → dp

Updated

19 years ago
Blocks: 33099

Comment 4

19 years ago
DP, do you have any status on this?

I've talked to Shaver about the matter of link-time dependencies on xpcom.lib 
and he feels it's downright impossible to avoid them, considering nsCOMPtr and 
all.  However, I still feel that nsServiceManager and nsComponentManager 
shouldn't be visible to #includers of nsIServiceManager, etc.

Can you please post some status, or at least take this out of the UNCONFIRMED 
state?

Thanks,

Ed

Updated

19 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
Target Milestone: --- → M16

Comment 5

19 years ago
Sorry. My query for looking at bugs missed all UNCONFIRMED bugs.

Shaver is right; we got to be clear on what you are trying to achieve. Can you 
be more clear on this.

Updated

19 years ago
Status: NEW → ASSIGNED

Comment 6

19 years ago
I dont see either of the nsIServiceManager.h or nsIComponentManager.h including
nsServiceManager.h and nsComponentManager.h  So I dont understand what you want
fixed here.

Comment 7

19 years ago
nsIComponentManager.h includes nsComponentManagerUtils.h, which declares
nsComponentManager.  

http://lxr.mozilla.org/mozilla/source/xpcom/components/nsIComponentManager.idl#98
http://lxr.mozilla.org/mozilla/source/xpcom/components/nsComponentManagerUtils.h#68

So this is still a problem.

Please post if you need more info.

Comment 8

19 years ago
I understand. Moving definition of the global nsComponentManager and
nsServiceManager out of the interface header paths is going to be costly tree
exercise. Nevertheless, I agree it is a good thing to do.
Keywords: helpwanted
Target Milestone: M16 → M20

Comment 9

18 years ago
Moving all current open XPCOM and XPCOM Registry bugs to rayw since dp is on 
sabbatical.  rayw is now default assignee for these components.
Assignee: dp → rayw
Status: ASSIGNED → NEW

Updated

18 years ago
Status: NEW → ASSIGNED

Updated

18 years ago
Keywords: nsbeta3, patch
Whiteboard: nsbeta3

Comment 10

18 years ago
I hadn't realized before now that there was a patch with this.  I just got a 
message from Sun indicating a reliance on this and a need to get it fixed for 
OJI by beta3.

Comment 11

18 years ago
Assigning rest of xpcom stuff to myself (from Ray).
Assignee: rayw → warren
Status: ASSIGNED → NEW
Target Milestone: M20 → mozilla1.0

Comment 12

18 years ago
Hi Warren, 

ANy chance of getting this in the trunk?

Updated

18 years ago
QA Contact: leger → kandrot

Comment 13

17 years ago
reasigning warren bugs to default component owners.
Assignee: warren → kandrot
QA Contact: kandrot → scc
Target Milestone: mozilla1.0 → ---
(Assignee)

Comment 14

17 years ago
reassign all kandrot xpcom bug.
Assignee: kandrot → dougt
(Assignee)

Updated

17 years ago
Blocks: 98278
(Assignee)

Updated

17 years ago
Target Milestone: --- → mozilla1.0
(Assignee)

Updated

17 years ago
Keywords: mozilla1.0
(Assignee)

Comment 15

17 years ago
Frozen interfaces will not have any implementation code unless completely
needed.  We are also wrapping this code with a MOZ_STRICT_API similar to what
you are suggesting.  

Marking this bug fixed since our standard operating procedure is to remove
implementation code from frozen iterfaces..
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.