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