i18n testing issue

[Norbert Lindenberg]

On Feb 6, 2013, at 12:14 , Nebojša Ćirić wrote:

> Does the test:
> intl402/ch11/11.3/11.3.2_1_a_ii.js

This tests the behavior of the function returned by Intl.NumberFormat.prototype.format with various values for the "value" argument. We'd like the argument to be a number. The normal pattern for the built-in functions in the ECMAScript Language specification is not to reject argument values that aren't of the desired type, but to use the appropriate To<Type> function to convert to the desired type. Here, that's ToNumber.

> has a conflict with:
> intl402/ch13/13.2/13.2.1_1.js

This tests the behavior of Number.prototype.toLocaleString with various "this" values (not arguments). For "this" values, the ECMAScript Language is usually stricter and expects that the value provided is of the required type (exceptions such as generic Array methods are called out with Notes in the spec). Using normal method dispatch you'd never reach methods with "this" values of the wrong type; you have to manually transfer the function to another object, set up prototype chains, or use Function.prototype.apply or (as in the test) Function.prototype.call to even get here.

Note that for toLocaleString a generic function is defined on Object.prototype and therefore available for all objects - the function tested here is the specialization for Number.

> Also, where in the spec (I was looking at the NumberFormat abstract method) do we deal with input type? It just says that x has to be a Number but not what happens if it's not (or I missed it).

Input type conversions generally happen as close to API-level as possible (an exception is that the Initialize operations delegate this task to the CanonicalizeLocaleList operation). Where the specification of an abstract operation says that an argument must be of a certain type or meet additional constraints, it means that the specification of the caller(s) must ensure that the requirements are met - read it as an assertion. In the case of FormatNumber, it's the call to ToNumber in step 1.a.ii of the getter that ensures that "x" has the required type.

Norbert