Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)
mjs at apple.com
Sat Sep 26 16:31:54 PDT 2009
On Sep 26, 2009, at 3:13 PM, Allen Wirfs-Brock wrote:
>> From: Maciej Stachowiak [mailto:mjs at apple.com]
>>> On Sep 26, 2009, at 8:28 AM, Allen Wirfs-Brock wrote:
>>> the semantics of "browser ECMAScript" has been arbitrarily split
>>> two independently maintained standards.
>> Is there any concrete concern on this front other than property
>> access catchalls?
> Every place the WebIDL ECMAScript binding "overrides" an ECMAScript
> internal method is a concern as these are special case extensions to
> the ECMAScript
> semantics. As language designers we need to understand if these
> special cases are
> exemplars of general deficiencies in the language that should be
We have definitely identified catchall property access as such an
area. Are there in fact any others? It's a lot more interesting to
look at specific examples than to expound on the general principles.
See below where I did some study to find other missing capabilities.
> In particular now that ES5 is finished, WebIDL has a richer
> language to bind to then
> it had with ES3. We need a WebIDL binding that maximizes use of ES5
> capabilities rather
> than inventing non-standard (from an ES perspective) language
Updating WebIDL to use ES5 concepts would definitely be worthwhile. At
the time Web IDL was started (early 2007 I think) this wasn't a
practical option, but it is now. In particular, interfaces that don't
have any unusual behavior could be defined as having getters and
setters, and should not need to override internal properties at all.
This would better highlight the capabilities that are needed to
implement the Web platform, but which can't be expressed in the
property descriptor formalism.
I expect there are relatiively few such capabilities, and little
interest in depending on new ones, and therefore we do not really have
a general ongoing problem of language design.
From a quick scan of WebIDL, I see the following:
1) Catchall getters, putters, deleters, definer.
- Variants that can make the catchall check happen either before
or after normal property lookup.
- General string-based name access and index-only versions.
- Note: I think catchall deleters are used only by Web Storage and
not by other new or legacy interfaces.
2) Ability to support being called (via [[Call]]) without being a
3) Ability to support being invoked a constructor (via [[Construct]])
without being a Function.
4) Ability to support instanceof checking (via [[HasInstance]])
without being a constructor (so myElement instanceof HTMLElement works).
5) Ability to have [[Construct]] do something different than [[Call]]
instead of treating it as a [[Call]] with a freshly allocated Object
passed as "this".
Tentatively, I think all other semantics of Web IDL interfaces can be
implemented in pure ES5.
More information about the es-discuss