Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)
Allen.Wirfs-Brock at microsoft.com
Sat Sep 26 17:20:48 PDT 2009
>From: Maciej Stachowiak [mailto:mjs at apple.com]
>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.
We have an ongoing problem of language design in that all new language
features must integrate with existing features. Combinatory feature
interactions is one of the larger challenges 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.
No comment, I need to come up to speed on the detailed semantic requirements
> - Note: I think catchall deleters are used only by Web Storage and
>not by other new or legacy interfaces.
Seems like a strong reason to change to the proposed API to eliminate the need for
a new ES language extension.
>2) Ability to support being called (via [[Call]]) without being a
Not an issue with the core ES5 semantics. Most ES3/5 section 15 functions have this
characteristic. As long as such WebIDL objects are defined similarly to the "built-in"
function they too can have this characteristic. It may well be useful to introduce a
mechanism defining such "pure" functions in the language but it probably isn't necessary
to proceed with the WebIDL binding. The important thing to try to avoid is specify
a custom [[Call]]
>3) Ability to support being invoked a constructor (via [[Construct]])
>without being a Function.
Essentially same as 2 although the standard [[Construct]] requires a [[Call]] so this
may need some more thought.
>4) Ability to support instanceof checking (via [[HasInstance]])
>without being a constructor (so myElement instanceof HTMLElement works).
Possibly the specification of the instanceof operator needs to be made extensible
>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".
Similar to 4 regarding extensibility. At least one recent "harmony" strawman proposal is
moving in a direction that may be relevent to 4 and 5.
>Tentatively, I think all other semantics of Web IDL interfaces can be
>implemented in pure ES5.
More information about the es-discuss