From: es-discuss <[email protected]> on behalf of Boris Zbarsky <[email protected]>
> 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. _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
