W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2011

Re: Implementation requirements for [Callback] interfaces

From: Cameron McCormack <cam@mcc.id.au>
Date: Thu, 16 Jun 2011 12:34:42 +1200
To: David Flanagan <dflanagan@mozilla.com>
Cc: public-script-coord@w3.org, Jonas Sicking <jonas@sicking.cc>
Message-ID: <20110616003441.GG21000@wok.mcc.id.au>
David Flanagan:
> So NodeFilter needs an interface object to define constants on, and
> XPathNSResolver needs an interface object and a prototype object
> because there might actually be host objects that inherit from the
> prototype.  Should WebIDL require implementations to define
> NodeFilter.prototype?

Good question – probably not?  How should we indicate this?  Would it be
sufficient in prose to say something like “If no host objects can
implement the interface, then the prototype property of the interface
object instead does not exist”?  Or do we need a [NoPrototypeObject] or
similar to allow specifications to explicitly indicate this?

(If we do invert the meaning of [NoIntefaceObject] on callback
interfaces to [RequireInterfaceObject], then we would do that too for
[NoPrototypeObject].)

> And if so, that presumably means that the DOM Traversal spec needs
> to specify the default behavior of NodeFilter.prototype.acceptNode()
> and similarly for any other spec that defines a [Callback] interface.

Yeah, if the function exists it needs to have some defined behaviour.

> (Unless, WebIDL specifies that these dummy methods do nothing and
> return undefined, but that then violates their signature).

They could throw an exception indicating that they have no
implementation.

-- 
Cameron McCormack ≝ http://mcc.id.au/
Received on Thursday, 16 June 2011 00:35:17 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:03 UTC