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

> From: Boris Zbarsky [mailto:bzbarsky@MIT.EDU]
> 
> 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?

In IE, we have an extended attribute that also provides for an interface object w/out a prototype: [msInterfaceObjectOnly]. It was primarily useful for things like NodeFilter. With support for the semantics of callback interfaces, most of the need for this goes away--however there are just a few cases like window.URL for which something like this is useful. In my humble opinion, what File API wanted to do was use the legacy WebIDL "module" feature which basically gives them what they want as far as a namespace for adding more properties.

I believe that firstly, the File API spec needs to be rationalized against the URL API which seems to indicate that the interface URL { } will behave more like a "normal" interface object. Once that happens, I wonder if there are any other lingering objects for which the "prototype-less" interface object would be needed.

Received on Friday, 21 September 2012 16:40:08 UTC