102874 - evangalize - most objects lack getInterfaces

Status: RESOLVED INVALID

(Core :: XPCOM, defect)

Description

[Jon Smirl]

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

[John Bandhauer]

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).

Comment 2

[Jon Smirl]

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.

Comment 3

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

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

[Doug Turner (:dougt)]

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?

Comment 5

[Jon Smirl]

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?

Comment 6

[Doug Turner (:dougt)]

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.

Comment 7

[basic]

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

Comment 8

[Vedran Miletic]

retargeting