User:Waldo/Internationalization API: Difference between revisions

User:Waldo/Internationalization API (view source)

Revision as of 06:08, 28 April 2013

428 bytes added , 28 April 2013

no edit summary

Norbert

3

edits

Revision as of 01:45, 28 April 2013 (view source) Norbert (talk \| contribs) No edit summary ← Older edit		Revision as of 06:08, 28 April 2013 (view source) Norbert (talk \| contribs) No edit summary Newer edit →
Line 162:		Line 162:

	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).		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).

			The size of ICU, especially its impact on download size, is an issue for Mozilla distribution. A document that Norbert wrote during the discussion of including ICU in desktop Firefox is somewhat out of date, but summarizes and comments on a number of ideas for reducing the size of ICU: [http://lindenbergsoftware.com/mozilla/implementation.html Implementation Options for ECMAScript Internationalization API in SpiderMonkey].