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.
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).
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.
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?
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?
Summary: most objects lack getInterfaces → evangalize - most objects lack getInterfaces
Target Milestone: --- → mozilla1.0
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
I think this should have gone to the newsgroup/mailing lists for discussions before ending up being a bug here.
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.