i18n testing issue

[Nebojša Ćirić]

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ć
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130207/1c58e4fe/attachment.html>