Mark Hammond wrote:
>
> John Bandhauer wrote:
>
> > In general wrappedJS wrappers are going to give you a different pointer
> > for every interface you QI it for - even if those interfaces
> > share an inheritance relationship. The exception is nsISupports
> > which *sometimes* shares a wrapper with another interface. Any
> > xpcom object might also do this - so your code should be ready for
> > this - but wrapped JS objects do it more.
>
> Just FYI, Python is very similar to js in this regard.
>
> > You should *never* be expecting equality of pointers that have not
> > been QI'd to the same interface.
>
> I thought the rules specifically state nsISupports? (I can't find a
> reference!) I don't believe there are guarantees the same pointer will
> be returned for any other interface than nsISupports? Whenever I
> compare pointers I am very careful to QI for nsISupports on both - even
> when they are the same IID. Is this unnecessary?
>
> Actually, I should re-phrase the question - I am almost certain it is
> currently unnecessary for all implemented components. But is it legal?
Good point. Funny, this has come up in three different
conversations I've had lately. The consensus seemed to be that
there is no reason the tearoff implementations might not do this.
They are *certainly* free to return different pointers to the
same interface that are not in use at the same time: A asks for
nsIFoo -> A releases nsIFoo -> A again asks for nsIFoo. I think
we are all agreed that A can not safely expect the same pointer
each time.
jst has told me that he has DOM tearoffs that might repeatedly
return different pointers even if there is no intervening
release. This frees the main object from the overhead of tracking
its tearoffs - though the back pointer form the tearoff to the
main object is required in order to make identity work.
Don Box et al's _Effective COM_ (aka Box II) discusses this on
pages 47-52 where he calls this legal, but a 'loophole' in the
COM spec. He goes on to show how this can cause problems when
interacting with the MSCOM proxy manager.
I'd say that xpcom considers this legal, but suspect.
XPConnect will not itself reflect anything such that the caller
will be able to see different pointers to the same QI'd
interfaces at the same time. Even if the underlying object does
this, xpconnect won't expose it that way because it will not
re-QI to an interface for which it already has a live wrapper
ready to hand out.
John.
>
> Thanks,
>
> Mark.
