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

On Tuesday, January 26, 2010 9:57 PM, Mark S. Miller [mailto:erights@google.com] wrote:
  Hi Travis, I am interested. I think many of the people on this list would be as well. Do you have an info about your ES5 bindings that you could post? Thanks.


(subject changed)
Thanks for your interest Mark.

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.
   * 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).
   * 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.
   * 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 ☺

Some minor changes include:
   * The ability to specify an “interface object only” interface (e.g., NodeFilter, needed for the W3C DOM L2 Traversal spec)
   * A strongly-defined [Supplemental] extended attribute
   * 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.

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.

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.

That about sums it up.

Received on Friday, 29 January 2010 16:56:45 UTC