i18n testing issue

[Norbert Lindenberg]

They aren't free to decide: If the callee is in strict mode, it has to receive what the caller provided; if it's non-strict, then undefined and null are replaced by the global object (ES5.1, 10.4.3). But the global object isn't a number either...

Norbert


On Feb 7, 2013, at 8:55 , Nebojša Ćirić wrote:

> Wrt. the 13.2.1_1.js. It seems that Chrome doesn't pass undefined to the toLocaleString from .call method, but you get Window instead (or whatever global this is), so the function never fails (in my case).
> I think implementations are free to pass non-undefined in .call if the object value is undefined.
> 
> 
> 2013/2/6 Norbert Lindenberg <ecmascript at norbertlindenberg.com>
> 
> 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
> 
> 
> 
> -- 
> Nebojša Ćirić