IDL enumeration & String.prototype.normalize
On Aug 6, 2013, at 7:59 AM, Anne van Kesteren wrote:
In IDL not being part of an enumeration throws TypeError. It seems String.prototype.normalize uses RangeError. I've no preference as to which is better, but it would be good if they were equal.
The argument to String.prototype.noralization is not an enumeration (not an ES concept) but a string. If the agument can not be converted to a string value, a TypeError is thrown. If the string value is not within the range of expected values, a RangeError is thrown. This is all normal ES conventions.
Also, throughout the platform we typically lowercase enumeration constants, e.g. "arraybuffer". I think it would be good for String.prototype.normalize to follow that precedent and use "nfc" etc.
The argument values aren't enumeration constants. They are string values that are the exact the abbreviations used by the Unicode standard to identify normalization forms.
(I was a bit surprised to see Unicode normalization exposed here. We've been pretty hesitant elsewhere to introduce dependencies on it, but I guess at this level it might be okay.)
see strawman:unicode_normalization for the rationale.
On Tue, Aug 6, 2013 at 4:32 PM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
The argument to String.prototype.noralization is not an enumeration (not an ES concept) but a string. If the agument can not be converted to a string value, a TypeError is thrown. If the string value is not within the range of expected values, a RangeError is thrown. This is all normal ES conventions.
An IDL enumeration bottoms-out to that, though. It's just a high-level concept (as are most IDL things) to enforce some level of consistency across APIs. That you instead describe it in terms of the low-level equivalent should not matter much for how we reason about them, unless I'm missing something.
Right, I think both are indeed enums at some conceptual level. IDL gives that concept a name; ES does not. It would be nice if IDL enums followed ES semantics, of doing ToString(value) (which may throw a TypeError) and then throwing a RangeError if outside the allowed range.
However, the definition of RangeError probably needs some updating in that case:
Indicates a numeric value has exceeded the allowable range.
On Tue, Aug 6, 2013 at 11:50 AM, Domenic Denicola < domenic at domenicdenicola.com> wrote:
Right, I think both are indeed enums at some conceptual level. IDL gives that concept a name; ES does not. It would be nice if IDL enums followed ES semantics, of doing
ToString(value)(which may throw aTypeError) and then throwing aRangeErrorif outside the allowed range.However, the [definition of
RangeError][1] probably needs some updating in that case:Indicates a numeric value has exceeded the allowable range.
Can you file a bug here: bugs.ecmascript.org/enter_bug.cgi?product=Draft for 6th Edition
On Aug 6, 2013, at 10:24 , Rick Waldron <waldron.rick at gmail.com> wrote:
Can you file a bug here: bugs.ecmascript.org/enter_bug.cgi?product=Draft for 6th Edition
I filed that ticket almost two years ago: ecmascript#224
In IDL not being part of an enumeration throws TypeError. It seems String.prototype.normalize uses RangeError. I've no preference as to which is better, but it would be good if they were equal.
Also, throughout the platform we typically lowercase enumeration constants, e.g. "arraybuffer". I think it would be good for String.prototype.normalize to follow that precedent and use "nfc" etc.
(I was a bit surprised to see Unicode normalization exposed here. We've been pretty hesitant elsewhere to introduce dependencies on it, but I guess at this level it might be okay.)