Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)
mjs at apple.com
Sat Sep 26 18:08:36 PDT 2009
On Sep 26, 2009, at 5:20 PM, Allen Wirfs-Brock wrote:
>> -----Original Message-----
>> 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
>> 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
They are pretty similar to the way Array overrides
[[DefineOwnProperty]] or the way String defines
>> - 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.
I previously argued for removing the need for catchall deleters from
the Web Storage API (since nothing else requires , but other browser
vendors (including Mozilla) were happy with it, and I think now
everyone (including I believe Microsoft) has implemented the spec
behavior. See prior discussion thread here: <http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-May/014851.html
>. At this point, since we have multiple deployed implementations of
Web Storage, we'd have to investigate whether it's safe to remove this
behavior without breaking content.
>> 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]]
I tend to agree that this behavior (and the next 3) are not
philosophically problematic, even though they cannot today be
implemented in pure ECMAScript.
>> 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
> 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
Interesting. This may provide a way to implement some of these
behaviors in pure ECMAScript. The current proposal does allow
[[Construct]] without [[Call]], but not [[Call]] and [[Construct]]
that both exist but with different behavior.
More information about the es-discuss