In WebIDL, should having a .prototype on interface objects be optional?

The spec currently says[1]:

   The value of the “prototype” property of an interface object for a
   non-callback interface MUST be an object called the interface
   prototype object.

At the same time, we have specs like File API defining things like this:

   partial interface URL {
   ....
   }

   ECMAScript user agents of this specification must ensure that they
   do not expose a prototype property on the URL interface object unless
   the user agent also implements the URL [URL API] specification. In
   other words, URL.prototype must evaluate to true if the user agent
   implements the URL [URL API] specification, and must NOT evaluate
   to true otherwise.

which flat-out contradicts the WebIDL text.

At the moment what Gecko is implementing is the following:  An interface 
object only has a .prototype property if it's not a callback interface 
and there can be actual objects with the relevant prototype on their 
proto chain.  So in our case we'd get the behavior File API calls for 
for free as long as we don't implement [URL API], but what we do is not 
compliant with WebIDL as it stands.

Should WebIDL change here?  Should FileAPI change?

-Boris

[1] http://dev.w3.org/2006/webapi/WebIDL/#interface-object
[2] http://dev.w3.org/2006/webapi/FileAPI/#creating-revoking

Received on Friday, 21 September 2012 14:01:15 UTC