Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)
mjs at apple.com
Sat Sep 26 23:43:16 PDT 2009
On Sep 26, 2009, at 10:55 PM, Allen Wirfs-Brock wrote:
>> -----Original Message-----
>> From: Cameron McCormack [mailto:cam at mcc.id.au]
>> When writing Web IDL originally, it didn’t seem at all to me that
>> objects were a disapproved of mechanism to get functionality that
>> be implemented with native objects. So having a [[Delete]] on a host
>> object be different from the Object [[Delete]] or the Array one
>> fine to me.
> The internal methods such as [[Delete]] aren't an actual extension
> They are a specification device used to define the semantics of
> ECMAScript. As
> such they are subject to change (there are significant changes in
> the ES5 spec.)
> and could even completely disappear if some edition of the ES
> specification chooses
> to adopt a different specification technique (which has been
ES5 seems to imply internal methods are an extension hook by using
them as such for a few built-in types, and by explicitly mentioning
they may behave arbitrarily differently for host objects. ES3 gave
this impression as well. While TC-39 seems to feel differently now, it
was very easy to get the impression by reading the spec that they are
indeed an extension hook. Beyond that, there doesn't seem to be any
other good way to soundly specify the behavior of a host object.
> Another issue with using specification internal methods as if they
> were an extension
> mechanism is that the ECMAScript specifications doesn't define any
> abstract contracts
> for them. What are the invariants that every [[Delete]] methods
> must maintain in order
> for the entire language to remain sound? It isn't currently
> defined. Within the ES spec.
> this isn't a big problem because most of the internal methods only
> have one definition
> within the ES specification and if there are more than one they have
> been designed
> with a unified semantics in mind.
> Why is functionality that isn't available through native objects
> needed? If it is possible
> to define Java bindings for WebIDL that don't require extending the
> Java language why isn't
> I understand the legacy issues).
A) For Web compatibility of pre-existing APIs.
B) In the case of some behaviors already used by pre-existing APIs,
it's useful for new APIs to behave the same way. Some examples: array-
style index access, and traditional details of call and construct
behavior. It would be confusing if every new DOM method behaved
differently from all previous DOM method, or indeed differently from
ECMAScript built-in methods. It would be confusing if all new DOM
constructors were Functions, but old ones aren't. ECMAScript built-in
objects themselves make use some techniques cannot be implemented in
pure ECMAScript, so it seems off-base to me to criticize DOM APIs for
doing the same thing.
[[Delete]] is a different kettle of fish, since overriding its
behavior was not done by either ECMAScript built-ins or any legacy
APIs. But keep in mind, most of the things we're talking about are
already done by Array instances, String objects, built-in
constructors, or built-in methods.
More information about the es-discuss