Specification styles

Domenic Denicola domenic at domenicdenicola.com
Thu Jan 30 09:52:59 PST 2014

From: es-discuss <es-discuss-bounces at mozilla.org> on behalf of Boris Zbarsky <bzbarsky at MIT.EDU>

> I would be interested in knowing what aspects of what you want to specify cannot be expressed in WebIDL + normal DOM spec style.....

Well, there's a lot of issues. The lack of data properties; the fact that all argument coercion and type-checking happens up-front (verus just-in-time checking if a callable property exists and throwing if it does not, for example); the inability to change return types based on the input (e.g. `return new this.constructor(...)` or `return firstArg`); the lack of care in handling abrupt completions; the lack of formalization around internal slots; the inability to support the ES6 inheritance and constructor model; the constant appeal to vague prose phrases; the lack of support for iterators; ...

Some of the type-related stuff could be handled within a WebIDL-using specification, by simply using `optional any` liberally and doing the work manually. Other issues are areas where WebIDL simply hasn't kept up with ECMAScript, and I imagine it will evolve to do so in the future. But the bottom line is, I want to be able to use the capabilities that JavaScript gives me, and second to writing JavaScript itself, ECMASpeak is a much better language for doing so than WebIDL + web-spec-style prose.

> What "situation" is that, exactly?

I was referring in particular to the contents of the referenced thread, wherein we discussed ways in which TextDecoder/TextEncoder didn't align with the ECMAScript model, e.g. exception type usage.

More information about the es-discuss mailing list