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

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

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Sun, 09 Dec 2012 23:16:44 -0500
Message-ID: <50C5622C.2060803@mit.edu>
To: Cameron McCormack <cam@mcc.id.au>
CC: public-webapps <public-webapps@w3.org>
On 12/9/12 10:41 PM, Cameron McCormack wrote:
> 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".

It needs to do special things with its return values, though...

> 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?

Yes.

> 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.

I believe those requirements are already slightly bogus in the face of 
scriptable plug-ins, for what it's worth...

But since the whole point of Custom Elements is to change what the 
primary interface of some elements is, I don't think that there's really 
a problem here.

> 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);
>    };

Yep.

-Boris
Received on Monday, 10 December 2012 04:17:15 GMT

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