Adam Lock wrote: > > John Bandhauer wrote: > > > Absolutely. QI to nsISupports and compare. Anyone breaking this > > rule should be spanked. > > > > John. > > What about the zillions of places where nsIAtom's are compared? > > Adam Sorry, I was too terse. The rule I meant was the COM identity rule that all interface pointers on the same object when QI'd to nsISupports must return the same address. [Note that we have one and only one special interface that objects are allowed to expose that does not follow this rule: nsIClassInfo. We decided that we needed to be able to easily get information about the implmentation class of xpcom objects without paying the per instance cost of an additional interface through which that inforamtion would be exposed. So, we decided that it would be OK to 'overload' QueryInterface to return (when asked for nsIClassInfo only) a pointer to an object that is the same object that all instances of that implmentation class return when asked for nsIClassInfo. Clearly, that nsIClassInfo pointer could not then be QI'd back to any particular one of those instances. This is a *very* special exception to the general rule.] As for nsIAtom... If you have special info about a particular class that tells you that it will never implement a given interface using a tearoff or some aggregation scheme then fine : compare the pointers for the given interface. We have such a rule about nsIAtom. But this is not general beyond nsIAtom. Sorry, You did also mention proxies... In COM you'd have cross process proxies. Objects proxied that way would only be exposed through the same proxy system (right?). So the nsISupports/IUnknown identity check would work. With the xpcom/proxy scheme I suppose it is *possible* to have access to the bare xpcom object and to the same object via an xpcom/proxy. If you are working with cases where this might come up and you need to perfectly detect identity of the underlying object then AFAICT you'd have to try building proxies around the objects just to figure out if one might already *be* a proxy (yuk). If you actually care about this situation ask dougt for details. John.
