General comment on ES 402 test suite (i18n)

[Nebojša Ćirić]

See comments inline.

2012/9/10 Norbert Lindenberg <ecmascript at norbertlindenberg.com>

> Hi Nebojša,
>
> Thanks for the information - this is really valuable data!
>
> My comments are embedded below. Some of them are based on my own two
> partial implementations:
>
> 1) The prototype/reference implementation that I've been maintaining for
> quite a while parallel to the spec prose, and which is loaded as a normal
> JavaScript library.
>
> 2) A port thereof into the new environment for self-hosted JavaScript
> within SpiderMonkey.
>
> The first one doesn't connect to a full internationalization library at
> all, and the connection for the second is still under construction, so some
> tests fail for this reason. In addition, I have a failure because
> SpiderMonkey bug 598996 prevents me from making the length of the array
> returned by supportedLocalesOf non-writable. Other failures are a subset of
> the ones you're discussing.
>
> Thanks,
> Norbert
>
>
> On Sep 7, 2012, at 14:31 , Nebojša Ćirić wrote:
>
> > I am making my implementation conform to the spec/tests as much as
> possible. It's currently passing  (P) 106, failing (F) 6 and expecting (EF)
> 25 to fail.
>
> What's the difference between "failing" and "expecting to fail"?
>

It's just annotation for myself, to tell me that I expect test x.y.z.js to
fail because of external issue (e.g. ICU bug, change in spec, something was
not implemented). The failing tests are either my bugs, or I didn't
investigate them deeper. You can treat all (FE and F) of them as failing
tests.


>
> > 3/25 EF are ICU problems, or ISO vs CLDR data differences. Bugs
> submitted, waiting for update.
>
> Can you provide bug IDs?
>

   # ICU bug http://bugs.icu-project.org/trac/ticket/9547
  'data/test/suite/intl402/ch11/11.3/11.3.2_TRP.js': 'FAIL',
  # ICU bug http://bugs.icu-project.org/trac/ticket/9265
  'data/test/suite/intl402/ch09/9.2/9.2.5_11_g_ii_2.js': 'FAIL'

 I don't have actual bug ID for ISO - CLDR issue (the fraction digits for
currencies). I'll talk to Mark about it.


> > 8/25 EF are from not implementing the i18n support for localeCompare and
> similar functions (yet).
>
> Looking forward to more info on this once you get there.
>
>
As soon as we ratify the spec :).



> > 6/25 EF are from not being able to detect if the function was called as
> constructor. V8 has a way of detecting that in C++ but there is no way to
> do it in JavaScript alone - which I need. Any pointers?
>
> Do you mean detecting in order to throw a TypeError when someone uses a
> non-constructor with new, or do you mean for purposes of differing behavior
> within an actual constructor? I see problems only with the first one in my
> prototype library. In the self-hosted environment in SpiderMonkey, there's
> no problem at all, because self-hosted functions by default are not
> constructors, and I have to call a special intrinsic %_MakeConstructible to
> register a function as a constructor.
>

Yes, it's related to the TypeError requirement. The way I did it was like
this:

JS code:

v8Intl {
...
function internalFormat(formatter, x) {
  ...
  return native function NativeJSFormatter(formatter, Number(x));
}
...
}

NativeJSFormatter is V8 C++ method and it can detect if it was called as
constructor or not. But by the time I call it it's already too late. It's
interesting that requirement like this is in ES spec, but they don't
provide a way to check/enforce it.


> I suspect that other ECMAScript functions implemented in JavaScript in V8
> don't meet this ES5 clause 15 requirement either.
>
> > 6/25 EF are from not being able to delete prototype property from a
> function. Any pointers?
>
> This is a problem in SpiderMonkey as well:
> https://bugzilla.mozilla.org/show_bug.cgi?id=784300
>
> As above, I suspect that other ECMAScript functions implemented in
> JavaScript in V8 don't meet this ES5 clause 15 requirement either.
>
> > 2/25 EF are from hour12 field being requested from resolvedOptions() in
> absence of hour field. Norbert said he would update this requirement in
> spec/tests.
>
> The spec change is in the September 4 draft, and I just updated the tests
> as well.
>

Thanks, both tests are passing now.


> > 1/6 F is from failing on de-DD locale test. I think we should remove
> this test case (does spec say anything about deprecated locales support?).
>
> 6.2.3 CanonicalizeLanguageTag refers to RFC 5646 section 4.5, and step 3
> of that section says "Subtags are replaced by their 'Preferred-Value', if
> there is one." The entry for region DD in the IANA Language Subtag Registry
> has Preferred-Value DE.
> http://tools.ietf.org/html/rfc5646#section-4.5
> http://www.iana.org/assignments/language-subtag-registry/
>
> I could file an ICU bug for this one. I'll take a look.


> > 2/6 F are from 1x.3_a.js tests, where 0 property of Array.prototype is
> tainted. I don't know how to guard against this. Any pointers?
>
> You mean 9.2.1_2.js and 9.2.6_2.js? The spec here refers to the List
> specification type, and I implemented List objects using Array methods that
> you have to grab before anybody can replace them.
>

Methods are fine, but what do you do with '0' property. You can't grab all
indices in range to protect override.


>
> > 3/6 F are from invoking Constructor.prototype.format/compare directly.
> I'll have to find a way to deal with these 3.
>
> What's the problem you're seeing?
>
>
I have to check why:

Object.defineProperty(Intl.Collator, 'prototype', new Intl.Collator())

doesn't provide expected result for me. Debugging time.

-- 
Nebojša Ćirić
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120910/f9777896/attachment-0001.html>