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

Allen Wirfs-Brock Allen.Wirfs-Brock at microsoft.com
Sat Sep 26 22:55:48 PDT 2009


>-----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 host
>objects were a disapproved of mechanism to get functionality that can’t
>be implemented with native objects.  So having a [[Delete]] on a host
>object be different from the Object [[Delete]] or the Array one seemed
>fine to me.
>

The internal methods such as [[Delete]] aren't an actual extension mechanism.
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 discussed).

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
it possible to approach JavaScript in the same manner (for new APIs, I understand the legacy issues).

Allen


More information about the es-discuss mailing list