evangalize - most objects lack getInterfaces

RESOLVED INVALID

Status

()

Core
XPCOM
RESOLVED INVALID
17 years ago
7 years ago

People

(Reporter: Jon Smirl, Unassigned)

Tracking

Trunk
Future
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

17 years ago
Most XPCOM objects lack support for getInterfaces(). This interface should be 
made mandatory so that large numbers of object don't end up without it.

This has long term potential impact. For example development IDEs need 
getInterfaces() in order to build a UI describing methods on the objects. You 
can not build an equivalent to Microsoft's OleView. You can not write WSDL 
generators for SOAP calls. XSLT needs this for calling extension functions.

MSCOM supports this via the typelib. The equivalent info is missing from XPCOM.

This call can probably be supported for free by changing the generic module 
support for C. Other languages will be more complex. It would be much better to 
univerally fix this now, rather than having to retrofit it on an object by 
object basis latter.

Comment 1

17 years ago
That would be in nsIClassInfo. There's no way we are going to add this method to 
nsISupports as you suggested elsewhere. I'm not sure what you mean by mandatory. 
I'm interested in hearing what obstacle shaver hit in trying to make a 
table-driven QI scheme work. This would have supplied the perfect single source 
for QI and getInterfaces iid lists (of course, some override mechanism would be 
necessary to handle fun cases where there is need for these lists to not 
match).
(Reporter)

Comment 2

17 years ago
What is the consensus opinion on this issue? I can always add getInterfaces to 
the components I care about. It's the long term general problem of getting lots 
of components (maybe without source) out there without this ability that 
bothers me. 

XPCOM and the set components that comprise Mozilla looks more like a platform 
to me than a browser. And there are major advantages to a system where the same 
component can run either at the server or the browser. getInterfaces() is 
neccessary to build tools for this future environment.
The big problem I had (see bug 23737) was that it was a net space loss.  That
may well no longer be the case if it saves us a second copy of the UUIDs for
nsIClassInfo::getInterfaces.

I can pick that work up again after I'm done with nsXULElement whipping, perhaps.

Comment 4

17 years ago
Jon, I think that we just have to avocate the use of nsIClassInfo.  If you see
core mozilla components that need nsIClassInfo, fire off a bug.  Bug I don't see
us going through systematically changing everyone.

Maybe we should just make this a meta bug.  What objects are you interested in
that lack getInterfaces?
(Reporter)

Comment 5

17 years ago
Right now it's my objects that are missing this but I am adding it to them. I 
felt that this was a longer term problem. At some point we are going to want to 
start making things like dev tools or documentation generators that need to 
know the interfaces. I would prefer to support this as soon as possible to stop 
from getting a lot of legacy objects without it. Is Mozilla's future to be just 
a browser or is it a programming platform?

Updated

17 years ago
Summary: most objects lack getInterfaces → evangalize - most objects lack getInterfaces
Target Milestone: --- → mozilla1.0

Updated

17 years ago
Keywords: mozilla1.0

Comment 6

17 years ago
Jon, I am not sure what I really can do about this "bug" you wrote up.  Maybe 
you can think of a solution.  Back to you.
Assignee: dougt → jonsmirl

Comment 7

17 years ago
I think this should have gone to the newsgroup/mailing lists for discussions
before ending up being a bug here.

Comment 8

15 years ago
retargeting
Target Milestone: mozilla1.0 → Future
Assignee: jonsmirl → nobody
QA Contact: scc → xpcom
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.