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