Bug 16537 - Interface types - Implements is ambiguous
Summary: Interface types - Implements is ambiguous
Status: RESOLVED WORKSFORME
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: WebIDL (show other bugs)
Version: unspecified
Hardware: PC Windows 3.1
: P2 normal
Target Milestone: ---
Assignee: Cameron McCormack
QA Contact: public-webapps-bugzilla
URL:
Whiteboard: [v1]
Keywords:
Depends on:
Blocks:
 
Reported: 2012-03-27 15:39 UTC by Marcos Caceres
Modified: 2013-08-06 01:27 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marcos Caceres 2012-03-27 15:39:29 UTC
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)
Comment 1 Marcos Caceres 2012-03-27 15:44:00 UTC
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.
Comment 2 Marcos Caceres 2012-03-27 15:48:37 UTC
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.
Comment 3 Boris Zbarsky 2012-03-27 15:55:35 UTC
> 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.
Comment 4 Marcos Caceres 2012-03-27 16:58:02 UTC
(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?
Comment 5 Boris Zbarsky 2012-03-27 22:55:55 UTC
Interoperate in what sense?
Comment 6 Marcos Caceres 2012-03-27 22:57:41 UTC
(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 :) )
Comment 7 Boris Zbarsky 2012-03-27 23:01:15 UTC
"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?
Comment 8 Marcos Caceres 2012-03-27 23:12:03 UTC
(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
Comment 9 Cameron McCormack 2012-03-27 23:22:32 UTC
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.
Comment 10 Cameron McCormack 2013-08-06 01:27:45 UTC
Marcos tells me this bug can be closed.