This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
In "4.2.18. Interface types", it says: "If V is a platform object that implements I, then return the IDL interface type value that represents a reference to that platform object." But it doesn't say how to check "that V implements I". Should implements link to something? I would have expected an algorithm for checking how one thing implements another thing. Also, "return the IDL interface type value that represents a reference to that platform object" seems verbose. I'm not sure what you want me to return there? just "return V"? or "return new V()"? :/ (sorry if I missed something previously about this, I'm cherry picking parts to implement out of order)
Ah, found it... it was in the next step: "If V is a user object that is considered to implement I according to the rules in section 4.7, then return the IDL interface type value that represents a reference to that user object." Can you please merge the two steps and make them a bit more clear.
Oh no, the next step applies to user objects not platform objects (so section 4.7 doesn't apply). Argh. Sorry. The issue in the original description of the bug may still apply.
> I'm not sure what you want me to return there? It depends on your binding and DOM implementation, no? For example, in the JSC bindings for WebKit, static_cast<I*, V.toImpl()> would be returned in many cases. In the WebIDL-based Spidermonkey bindings for Gecko, UnwrapDOMObject<I>(V) would be returned in many cases. In the old XPIDL-based Spidermonkey bindings for Gecko, static_cast<I*,JS_GetPrivate(V)> would be returned in many cases. Basically, you return whatever your DOM implementation internally considers to be "an instance of I". For the C++ DOM implementations mentioned above, that would be a pointer to whatever object type the implementation considers to implement the interface I internally. But what you want to return just depends on your implementation.
(In reply to comment #3) > > I'm not sure what you want me to return there? > > It depends on your binding and DOM implementation, no? I guess so... > For example, in the JSC bindings for WebKit, static_cast<I*, V.toImpl()> would > be returned in many cases. > > In the WebIDL-based Spidermonkey bindings for Gecko, UnwrapDOMObject<I>(V) > would be returned in many cases. > > In the old XPIDL-based Spidermonkey bindings for Gecko, > static_cast<I*,JS_GetPrivate(V)> would be returned in many cases. > > Basically, you return whatever your DOM implementation internally considers to > be "an instance of I". For the C++ DOM implementations mentioned above, that > would be a pointer to whatever object type the implementation considers to > implement the interface I internally. But what you want to return just depends > on your implementation. Ok, I see. I havent' looked at those methods but will try to find them, but I guess they interoperate enough that it is not an issue across browsers, right?
Interoperate in what sense?
(In reply to comment #5) > Interoperate in what sense? in the sense that "If V is a platform object that implements I, then return the IDL interface type value that represents a reference to that platform object." (i.e., the correct thing is returned across browsers... which I'm still unsure what that is :) )
"correct" in what sense? The point is that it should return whatever your actual DOM implementation considers to be an implementation of I. Since the resulting value is never exposed directly to user script, and in fact may well not even be a value in JavaScript if your DOM implementation is in some other language, what sort of interoperability are we talking about?
(In reply to comment #7) > "correct" in what sense? The point is that it should return whatever your > actual DOM implementation considers to be an implementation of I. Since the > resulting value is never exposed directly to user script, and in fact may well > not even be a value in JavaScript if your DOM implementation is in some other > language, what sort of interoperability are we talking about? Sorry, maybe I'm getting confused because I am implementing it as a user script. My understanding is that this algorithm is used when I have the following: interface Foo{ attribute Bar? pub; } [Constructor] interface Bar{} //Then... in JS land.... var placeToDrink = new Bar(); someFooObj.bar = placeToDrink; //this is ok, do what the spec says. someFooObj.bar = "The pig and whistle"; //throws TypeError
Your implementation of the IDL needs to know whether a given object implements a particular interface. You might have some hidden state somewhere that keeps track of all objects that get constructed through "new Bar()" for example. All objects that get constructed through "new Bar()" must be objects that implement Bar, note, because the algorithm for interface object [[Call]] says that it returns an object that implements the interface.
Marcos tells me this bug can be closed.