W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2012

Re: [WebIDL] Representing functions that user code can call

From: Cameron McCormack <cam@mcc.id.au>
Date: Mon, 10 Dec 2012 14:41:26 +1100
Message-ID: <50C559E6.2020103@mcc.id.au>
To: Boris Zbarsky <bzbarsky@MIT.EDU>
CC: public-webapps <public-webapps@w3.org>
On 9/12/12 1:51 PM, Boris Zbarsky wrote:
> The relevant part of the spec is:
>
>    The result of converting an IDL callback function type value to an
>    ECMAScript value is a reference to the same object that the IDL
>    callback function type value represents.
>
> which presupposes that there's an ECMAScript object being represented by
> the IDL callback function type.  But in this case there isn't.  Such an
> ECMAScript object needs to get created...  Furthermore, the behavior of
> this object, when called, needs to be quite different from the normal
> behavior of ECMAScript function objects: it needs to convert its
> arguments to IDL types and then invoke some algorithm defined on IDL
> types.  Right now, all of that would have to be described in prose
> because there is no way to express it in WebIDL.

OK.  For Document.register, the Function object that is returned is not 
going to do anything with its arguments, so I don't think we gain much 
in this case compared to (to make the IDL valid) replacing "Function" 
with "object".

But if we did have a special type that meant "platform implemented 
function", what would we use as the return type for the custom element 
constructor function?  Is the object returned from it a platform Element 
object?  I guess we do want it to be considered as one, but the 
requirements for particular prototype chains that the Custom Elements 
spec has will go against the requirement in 
http://dev.w3.org/2006/webapi/WebIDL/#es-platform-objects that 
[[Prototype]] of the object be the interface prototype object for the 
object's primary interface.  (In fact the primary interface for object 
is probably not well defined.)

Anyhow, if we resolve that problem, then we could allow something like:

   function CustomElementConstructor = Element ();

   partial interface Document {
     CustomElementConstructor register(DOMString name,
                                       optional Options options);
   };
Received on Monday, 10 December 2012 03:42:00 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:56 GMT