- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Sat, 08 Dec 2012 21:51:08 -0500
- To: Cameron McCormack <cam@mcc.id.au>
- CC: public-webapps <public-webapps@w3.org>
On 12/8/12 7:07 PM, Cameron McCormack wrote:
> Is this for
>
> partial interface Document {
> Function register(DOMString name, optional Options options);
> };
Yes.
> ? Despite the name "callback function", I think they could be used
> here. I don't think there's anything in the spec that prevents platform
> objects from providing values of this type.
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.
>> Note that right now the web components spec is using callbacks for this,
>> but they're not a great fit given how callback conversions between
>> WebIDL and ES are defined...
>
> What about the conversion is a bad fit?
See above. The way the conversion is specified presupposes a situation
that just doesn't hold in this case.
> Maybe we could just rename callback functions to functions, and have
> them work both for user-provided and platform-object-provided Function
> values.
That doesn't work unless you define different argument conversion and
IDL-to-ES-and-back behavior for the two types of functions...
-Boris
Received on Sunday, 9 December 2012 02:51:40 UTC