Re: Thoughts on ES5 binding modifications (was: RE: Java bindings generated from Web IDL)

Cameron McCormack:
> > Note that even a [Replaceable] attribute is handled as an accessor
> > property.  Its [[Set]] reconfigures itself to a data property.

Travis Leithead:
> Excellent. In IE9, the [[set]] just adds an override to the window
> instance, "shadowing" the accessor on the prototype.

Actually that is what the spec requires, sorry:

  http://dev.w3.org/2006/webapi/WebIDL/#dfn-attribute-setter

The new property is defined on the instance.

> […]
>
> The above would create three copies of the addEventListener
> API on each of Window.prototype, Node.prototype, and
> XMLHttpRequest.prototype. We favored this simplicity over the desire
> to have a single addEventListener definition that could be configured
> to affect all implementing interfaces. The extra redundancy in API
> definitions hasn't posed a problem for us yet :)

OK.

> >> (Do you mean operation overloading?)  It might indeed be possible to remove the crazy language about 
> >> operator overloading currently in the spec, replacing it perhaps with default values and/or allowing union 
> >> types to be defined.  Noted an issue in the spec.

(See how I typed “operator overloading” there too? :))

> I would love to see a resolution to this. It's been challenging to
> implement the Canvas APIs which have some of the most complicated
> overloading I've yet encountered.

You mentioned at one point that you were able to “solve” the overloading
problem purely with specifying optional argument default values, is that
right?  How did you handle

  ImageData createImageData(in double sw, in double sh);
  ImageData createImageData(in ImageData imagedata);

?

Travis Leithead:
> > > * The ability to specify an “interface object only” interface
> > >   (e.g., NodeFilter, needed for the W3C DOM L2 Traversal spec)

Cameron McCormack:
> > Is that one that is only ever implemented by native objects?  The spec currently allows native objects to be 
> > passed in for such interfaces, but there’s no annotation to note that host objects will never implement it.
> > What benefit would that have?

Travis Leithead:
> Yes, currently our IE9 NodeFilter is wholly a native object, just
> present to provide the constants; it's not the same thing we allow in
> the createNodeIterator method, which must be a Function. 

OK, but I am not sure what specifying “interface object only” actually
means, then.  What would it change in the ES binding?  (The lack of a
prototype object?)

> However, the [Callback] EventListener interface is allowed (per
> definition of [Callback]) to accept a native object with a
> "handleEvent" function.
>
> On a related note, the definition of [Callback] (as opposed to
> [Callback=Function]) allows a native object _or function_ to be passed
> with an internal function property defined. This is the case with:
>
> [Callback]
> interface EventListener {
>     void handleEvent(Event event);
> };
> 
> So that the following works:
> addEventListener('eventname', { handleEvent: function(e) { /* processing */ } }, false);

Right.

> It's the part about the definition of [Callback] that allows for functions with an internal function that I don't like:
> 
> function MyScope() { }
> MyScope.handleEvent = function(e) { /* processing */ };
> addEventListener('eventname', MyScope, false);
> 
> Our implementation (IE9) is heavily optimized to handle a
> function pointer and simply register it. Having to account for a
> function-in-a-function will introduce a significant performance
> regression. If we could simple drop this requirement it would be
> great. Also, this is not supported in IE9, Firefox or Chrome recent
> builds.

I see.  Filed a bug:

  http://www.w3.org/Bugs/Public/show_bug.cgi?id=11185

> > > [global polluter extended attribute]
> >
> > Is this for things like <span id=abc> causing a global, replaceable
> > variable named "abc" to be available?
> 
> No, not the same thing. Our global object polluter attribute (module
> level) just tells which interface to hookup as the JavaScript global
> object's prototype :)

Specifying what object is returned by Object.getPrototypeOf(window)?
Can you demonstrate how such an extended attribute would be used?

Thanks,

Cameron

-- 
Cameron McCormack ≝ http://mcc.id.au/

Received on Sunday, 31 October 2010 22:31:57 UTC