On Aug 25, 3:35 am, "Jake Donham" <[EMAIL PROTECTED]> wrote:
> I am very confused about the role of QueryInterface when using XPCOM
> from Javascript. For instance, there are many nsI{Foo}Window
> interfaces, but I see extension code that uses methods from different
> interfaces without QIing among them. Is this behavior particular to
> windows or a general XPCOM/XPConnect thing?Just to answer questions as you asked them: This is a DOM behavior handled by XPConnect for JS (XPCOM doesn't really know/care except to the extent that it defines half of nsIClassInfo). > Does this have something to do with "aggregated" interfaces? Not generally. I suppose if you're dealing w/ nsIDOM3Node, then technically it probably does. But that's just an edge of the world case. > What about "flattened" Javascript wrappers? That's how the magic works > (I came across these terms but could find no definition of them.) Seems you found at least one good lead, I'm sorry that didn't get you to the right answer on your own. > If I understand correctly, QueryInterface (and instanceof) can be used > for their side-effect, which is to cache a "tear-off"--the underlying > C++ object appropriately cast--of the interface so that future method > calls against that interface succeed. Yes > What I can't figure out is what happens (or is supposed to happen) > if you make a call against an interface for which no tear-off is > cached--is one added automatically? In a certain respect, you can't do that. Not really anyway. An object has to know what properties it has (minus __noSuchMethod__ and some other similar thing). With ClassInfo (which you've found), the object (or rather xpconnect's reflection of the object) knows about all the available interfaces, and essentially if it wasn't doing Eager (classinfo) flattening, then when it doesn't have the answer, it will go hunting through the classinfo interfaces to find the match. More usefully: If an object "myObject" implements "myIFoo" with attribute "myBlah" but doesn't implement nsIClassInfo and you only have an nsISupports pointer, then: myObject.myBlah will trigger an exception (something like no such method nsISupports.myBlah). You could do: myObject.myIFoo.myBlah without triggering flattening (i.e. myObject.myBlah will still trigger an exception), this can be useful when there are collisions between flattened interfaces. but, as soon as you do: myObject instanceof Components.interfaces.myIFoo then, myObject.myBlah will work (for that one object instance, but generally in all scopes, even unrelated xpconnect scopes). > Is there a page somewhere that lays this all out for the uninitiated > (uninitialized?) among us? Many thanks, _______________________________________________ dev-tech-xpcom mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-xpcom
