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.
-Boris _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
