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

On Sep 26, 2009, at 10:55 PM, Allen Wirfs-Brock wrote:

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

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

Regards,
Maciej

Received on Sunday, 27 September 2009 06:44:01 UTC