RE: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)

>-----Original Message-----
>From: Maciej Stachowiak [mailto:mjs@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
>Function.

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.
See http://wiki.ecmascript.org/doku.php?id=strawman:obj_initialiser_constructors
 


>
>Tentatively, I think all other semantics of Web IDL interfaces can be
>implemented in pure ES5.
>
>Regards,
>Maciej
>

Received on Sunday, 27 September 2009 00:21:54 UTC