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 Friday, 8 October 2010 03:27:35 UTC