W3C home > Mailing lists > Public > public-script-coord@w3.org > October to December 2010

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

From: Travis Leithead <travil@microsoft.com>
Date: Thu, 21 Oct 2010 21:50:37 +0000
To: Cameron McCormack <cam@mcc.id.au>
CC: "Mark S. Miller" <erights@google.com>, Shiki Okasaka <shiki@google.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>, Adrian Bateman <adrianba@microsoft.com>
Message-ID: <9768D477C67135458BF978A45BCF9B381FDA5C@TK5EX14MBXW605.wingroup.windeploy.ntdev.microsoft.com>
Thanks Cameron.

From: public-script-coord-request@w3.org [mailto:public-script-coord-request@w3.org] On Behalf Of Cameron McCormack
>> Note that even a [Replaceable] attribute is handled as an accessor property.  Its [[Set]] reconfigures itself to a data property.

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

>> I haven’t changed much to do with mixin interfaces since the last draft.
>> I will come back to this issue after the next WD publication.  I’ve noted an issue in the spec for it.

OK, looking forward to a discussion around this. In IE9, we are mixing in interfaces (and inherited interfaces of mixin interfaces) onto the "implements" target's prototype.

For example:

[NoInterfaceObject]
interface EventTarget { 
    void addEventListener(..);
};

Window implements EventTarget;
Node implements EventTarget;
XMLHttpRequest implements EventTarget;

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 :)

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

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.

>> >    * The ability to specify an “interface object only” interface
>> >      (e.g., NodeFilter, needed for the W3C DOM L2 Traversal spec)
>> 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?

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

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.

>> 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 :)

>> A definition of a spec for an extended attribute causing IDL attributes to be reflected in content attributes 
>> might be a useful thing, although I think it would be better defined in another spec (HTML5 perhaps).
>> It’d probably save a bit of prose in HTML5.

Indeed. A nice-to-have for specs that define markup languages, but not a requirement.

>> I think they should remain in the spec but their use be heavily cautioned against, pointing out 
>> that they’re only to be used for legacy interfaces.

Great!


-Travis

-----Original Message-----
From: public-script-coord-request@w3.org [mailto:public-script-coord-request@w3.org] On Behalf Of Cameron McCormack
Sent: Thursday, October 07, 2010 8:27 PM
To: Travis Leithead
Cc: Mark S. Miller; Shiki Okasaka; public-script-coord@w3.org
Subject: Re: Thoughts on ES5 binding modifications (was: RE: Java bindings generated from Web IDL)

Travis Leithead:
> In general my changes for a ES5 binding boil down to two key principles:
> * The DOM must make sense in the context of ECMAScript 5's "reflection" APIs.
> * Should approximate being implemented natively in ECMAScript.
> 
> 
> My major changes from current WebIDL ECMAScript bindings are (in summary):
>    * Most DOM attributes are represented by accessor properties
>      (rather than data properties). I say “most” because [Replaceable]
>      forces some attributes to be data properties. Naturally, “const”
>      and “operations” are still data properties.

This is now required:

  http://dev.w3.org/2006/webapi/WebIDL/#es-attributes


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

>    * DOM attributes (as accessors) are “owned” by the prototypes that
>      declare them, rather than being “own” properties on the instances
>      of those prototypes. This makes DOM attributes and “operations”
>      be treated more-or-less equally (which I believe is a simpler
>      direct translation of an interface, as well as being convenient
>      for replacing accessor functionality on a broad scale in the DOM
>      (a specific use-case, but an important one to the IE team). This
>      also follows the prototype model introduced in IE8 with early
>      support for Object.getOwnPropertyDescriptor (thanks again Allen).

This is also now required.

>    * Mixin interfaces simply copy their contents to the interface that
>      they mix-in to. There’s no craziness (that’s my opinion)
>      involving a “mixin prototype object” as currently speced.
>      This also means there’s no multiple inheritance (though I think
>      that was pulled out of the editor’s draft a while ago)—just
>      standard use of the prototype chain.

I haven’t changed much to do with mixin interfaces since the last draft.
I will come back to this issue after the next WD publication.  I’ve noted an issue in the spec for it.

>    * No operator overloading. I added the concept of an
>      [msDefaultValue] (Microsoft-prefixed as a “friendly”
>      extension) extended attribute for parameter lists, and so
>      far--with only this addition--I’ve been able to spec all of
>      IE’s “operations” without the need for overloading or union
>      types (as Allen suggested previously). That’s my litmus test
>      for adding this attribute ☺

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

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

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?

>    * A strongly-defined [Supplemental] extended attribute

Yes, on the list of things to define.

>    * A “global polluter” module-level extended attribute for altering
>     the internal prototype of the global object instance. This loosely
>     follows what I’ve been able to observe from Gecko’s __proto__
>     property and related structure.

Is this for things like <span id=abc> causing a global, replaceable variable named "abc" to be available?

> I also created a number of minor extensions, such as declaratively 
> indicating the names of associated “content attributes” for DOM 
> attributes (pardon the HTML5 parlance), tag names for element 
> interfaces, security restrictions of various kinds, etc.

A definition of a spec for an extended attribute causing IDL attributes to be reflected in content attributes might be a useful thing, although I think it would be better defined in another spec (HTML5 perhaps).
It’d probably save a bit of prose in HTML5.

> I actually use some of the esoteric functionality currently defined in 
> WebIDL for the purpose of clarifying the behavior of many legacy IE 
> behaivors, such as the unpopular “caller” syntax, the “catch-all” 
> support via “getter”, “setter”, etc. I say this only because I believe 
> they are useful for specifying legacy behavior, not because I have a 
> strong position on whether they should actually remain part of the 
> WebIDL ECMAScript binding for use in future specs.

I think they should remain in the spec but their use be heavily cautioned against, pointing out that they’re only to be used for legacy interfaces.

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



Received on Thursday, 21 October 2010 21:51:26 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:03 UTC