- From: Allen Wirfs-Brock <Allen.Wirfs-Brock@microsoft.com>
- Date: Sun, 27 Sep 2009 05:55:48 +0000
- To: Cameron McCormack <cam@mcc.id.au>
- CC: Maciej Stachowiak <mjs@apple.com>, Brendan Eich <brendan@mozilla.com>, "public-webapps@w3.org" <public-webapps@w3.org>, Doug Schepers <schepers@w3.org>, HTML WG <public-html@w3.org>, es-discuss <es-discuss@mozilla.org>
>-----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). 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
Received on Sunday, 27 September 2009 05:56:42 UTC