Re: Implementation requirements for [Callback] interfaces

David Flanagan:
> As currently written, the WebIDL spec seems to require [Callback]
> interfaces to define an interface object and a prototype object, and
> to define properties on the prototype object, as if there will be
> host objects that will actually inherit those properties.  What is
> the point, for example, of defining
> EventListener.prototype.handleEvent, for example?  What should it do
> if invoked?

You are right (as you point out on www-dom) that EventListener should
have [NoInterfaceObject].

> Are there any specs currently using [Callback] for interfaces that
> exist as both host objects and native JavaScript implementations?

I don’t know how well it is implemented, but there is XPathNSResolver,
which both can be supplied from script and can be returned from a
createNSResolver call:

http://www.w3.org/TR/DOM-Level-3-XPath/xpath.html#XPathNSResolver
http://www.w3.org/TR/DOM-Level-3-XPath/xpath.html#XPathEvaluator-createNSResolver

> Are there any specs that define [Callback] interfaces that have
> constants?

None come to mind.

> If not, it sure would be simpler to say that the [Callback]
> attribute implies the [NoInterfaceObject] attribute.

It would indeed.  I am concerned there might be some valid use cases for
having an interface that can be implemented by both user script and the
implementation, but even so this would be uncommon.

In this kind of situation I might think to flip the extended attribute –
have a [RequireInterfaceObject] to override [Callback]’s default
behaviour of inhibiting the interface object.  Once the multiple
inheritance / mixin interface issue is resolved, it might be that mixins
are syntactically distinguished from regular interfaces and will all
automatically be [NoInterfaceObject].  That seems to be the main use of
[NoInterfaceObject] in specs at the moment, and I’m not sure without
poring through specs whether [NoInterfaceObject] would be useful in any
other cases.

-- 
Cameron McCormack ≝ http://mcc.id.au/

Received on Wednesday, 15 June 2011 05:45:50 UTC