Specification styles

Boris Zbarsky bzbarsky at MIT.EDU
Thu Jan 30 10:31:12 PST 2014

On 1/30/14 9:52 AM, Domenic Denicola wrote:
> The lack of data properties

That's fair.

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

This is a philosophical disagreement, agreed.

> the inability to change return types based on the input

WebIDL has this ability.  Either union types or object/any, depending on 
how much you want to change it.

> the lack of care in handling abrupt completions

Uh...  WebIDL does in fact define the handling of those if you operate 
on WebIDL objects.

Obviously if you want to operate on "object" or "any" you have to do it 
yourself as now.

> the lack of formalization around internal slots

This would look the same way in a WebIDL spec as in yours.

> the inability to support the ES6 inheritance and constructor model

WebIDL is supposed to support this.  If it doesn't, please file bugs.

> the constant appeal to vague prose phrases

Can you give an example?

> the lack of support for iterators

See discussion about sequence<>?

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

Exception type usage is the issue you're having in your ES version as 
well, right?   Seems like that's something that just needs to be fixed 
as needed and doesn't depend so much on the specification formalism.


More information about the es-discuss mailing list