Confirmed users
446
edits
User:Waldo/Internationalization API: Difference between revisions
Jump to navigation
Jump to search
User:Waldo/Internationalization API (view source)
Revision as of 18:09, 25 April 2013
, 25 April 2013Add more implementation details info
(Slightly more expansion of the testing details) |
(Add more implementation details info) |
||
| Line 87: | Line 87: | ||
==== Intrinsic functions ==== | ==== Intrinsic functions ==== | ||
Self-hosted code calls into various intrinsics to access ICU functionality. The full list of Internationalization intrinsics is (necessarily) in {{source|js/src/vm/SelfHosting.cpp}}, but the intrinsics themselves are implemented in {{source|js/src/builtin/Intl.cpp}}. | Self-hosted code calls into various intrinsics to access ICU functionality. The full list of Internationalization intrinsics is (necessarily, at the moment -- this will probably change eventually) in {{source|js/src/vm/SelfHosting.cpp}}, but the intrinsics themselves are implemented in {{source|js/src/builtin/Intl.cpp}}. | ||
==== Natively-implemented functions ==== | ==== Natively-implemented functions ==== | ||
| Line 105: | Line 105: | ||
=== Implementation === | === Implementation === | ||
... | ECMA-402 currently exposes <code>Intl.Collator</code>, <code>Intl.DateTimeFormatter</code>, and <code>Intl.NumberFormatter</code> objects. The spec also permits initializing an existing object as one of these, for a wrinkle. The fundamental ICU data structures providing the relevant functionality are <code>UCollator*</code>, <code>UNumberFormat*</code>, and <code>UDateFormat*</code>, opaque pointers all. Instances are created using <code>u{col,num,date}_open</code>, passing in appropriate arguments. For objects ''created'' by the constructor, the pointer is stored in a reserved slot as a private value. For objects merely ''initialized'' by the constructor, the ICU data structures must be (inefficiently!) created anew every time. | ||
Every object initialized as an Intl object has an associated set of internal properties. In ECMA-402 these properties are represented using ES5's traditional double-bracket notation: <code><nowiki>[[calendar]]</nowiki></code>, <code><nowiki>[[initializedIntlObject]]</nowiki></code>, and so on. The "ideal" means of implementing these properties would probably be ES6 private names, but they're not stable or well-understood enough to be specified yet (let alone implemented). In the meantime we associate ECMA-402 internal properties with objects using a weak map. Any object initialized as an <code>Intl</code> object has an internal <code><nowiki>[[initializedIntlObject]]</nowiki></code> property. This is implemented by placing all such objects as keys in a weak map (<code>internalsMap</code> in <code>builtin/Intl.js</code>). The corresponding value is an ''internals object''. The internals object is an object with properties corresponding to the other internal properties on the object, named naturally -- "calendar", "initializedDateTimeFormat", and so on (no brackets). | |||
=== Known issues === | === Known issues === | ||
| Line 112: | Line 114: | ||
The ICU interface that exposes a locale's default numbering system (see above) is C++, which (see below) means it's not stable. There's an [http://bugs.icu-project.org/trac/ticket/10039 issue] on file to add a C API for this. Until that's implemented and we use it, be careful about ICU upgrades. | The ICU interface that exposes a locale's default numbering system (see above) is C++, which (see below) means it's not stable. There's an [http://bugs.icu-project.org/trac/ticket/10039 issue] on file to add a C API for this. Until that's implemented and we use it, be careful about ICU upgrades. | ||
The means for representing internal properties ''may'' not be cross-global-correct. Technically if I do <code>var obj = {}; Intl.Collator(obj); otherWindow.Intl.Collator(obj);</code> the second initialization should throw, because internal properties adhere to the object. The current structuring of the weak map mechanism, however, uses one weak map per global. So that example likely "succeeds" now, where it actually shouldn't. This probably is unlikely to be simply stumbled upon, but it's an issue. Recent self-hosting work may allow us to not clone the internals-mapping behavior into every global object that uses <code>Intl</code> stuff, which would solve this issue. I (Jeff) should look into this at some point, and poke Till for review on a patch if it pans out (given he implemented the relevant self-hosting improvements). | |||
=== Other random details === | === Other random details === | ||
....anything?... | ....anything?... | ||