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

>-----Original Message-----
>From: Cameron McCormack []
>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).


Received on Sunday, 27 September 2009 05:56:55 UTC