W3C home > Mailing lists > Public > public-html@w3.org > September 2009

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

From: Cameron McCormack <cam@mcc.id.au>
Date: Sat, 26 Sep 2009 23:16:05 -0700
To: Allen Wirfs-Brock <Allen.Wirfs-Brock@microsoft.com>
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>
Message-ID: <20090927061605.GA5887@wok.mcc.id.au>
Allen Wirfs-Brock:
> 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).

OK, that is indeed what I’m hearing from you guys.  “Host objects may
implement these [internal] methods in any manner unless specified
otherwise” in ES3 doesn’t sound like it’s particularly discouraging of
the different behaviour that Web IDL prescribes.

> 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.

Or, defined to be “you can do anything”.  Which admittedly isn’t useful
if you are indeed trying to maintain some invariants.

> 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?

For web compatibility, really.

> 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).

Java really doesn’t have those compatibility issues.

Ignoring the legacy issues, assuming we have ES5 to build on, then yeah
it seems like most things can be done (from Maciej’s quick analysis).
The array like objects do seem like a useful pattern for authors to use,
though.

-- 
Cameron McCormack ≝ http://mcc.id.au/
Received on Sunday, 27 September 2009 06:16:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:49 GMT