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"? > 3/25 EF are ICU problems, or ISO vs CLDR data differences. Bugs submitted, > waiting for update. Can you provide bug IDs? > 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. > 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. 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. > 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/ > 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. > 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? _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
