Re: i18n testing issue

2013-02-07 Thread Allen Wirfs-Brock
The functions defined within the Ecma standards aren't specified using ECMAScript code so they aren't really either strict or non-strict. However, all the standard ES5 methods are specified assuming that the function gets what was actually passed. A standard method should never directly or indi

Re: i18n testing issue

2013-02-07 Thread 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

Re: i18n testing issue

2013-02-07 Thread 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 undefi

Re: i18n testing issue

2013-02-06 Thread 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 f

i18n testing issue

2013-02-06 Thread Nebojša Ćirić
Does the test: intl402/ch11/11.3/11.3.2_1_a_ii.js has a conflict with: intl402/ch13/13.2/13.2.1_1.js One expects support for format(undefined) while the other expects an TypeError. Also, where in the spec (I was looking at the NumberFormat abstract method) do we deal with input type? It just say