i18n objects

Shawn Steele Shawn.Steele at microsoft.com
Mon Jan 24 10:25:49 PST 2011

Considering last week’s discussion on the i18n objects, I think I’ll follow this pattern:

·         Constructor takes options, as specified

·         LocaleInfo takes an option to enable inferring.

o   Default to infer or not is an open question.

·         Have an isInferred() function to test if a property was inferred.

·         NO options property

·         Instead individual properties for each value.

·         Using the .derive method to derive a similar object.

Discussion of each of these should probably have individual threads unless they directly impact each other; last week’s thread wandered between topics without really resolving them.

My reasoning:

·         I didn’t use the options property because an options property is controversial, and leads to other “hard” questions, like:

o   Would options represent only the state when constructed?  Or the current state?  (Can they differ?)

o   Would options be read-only?  (And then how would you use it).

o   Would options be a writable copy (which sounds expensive to me)?

o   Would options be mutable?

·         It’s clear that we want to be able to infer or not.  If find the ability to set it in the constructor much simple.  A disadvantage is that a library would have to figure out if inputs were inferred by using isInferred().  An advantage is that when a worker doesn’t really care if data is inferred or not, then the caller can pass a correctly inferred (or not) object to the worker.

·         If there isn’t an options property, then there are fewer mechanisms to create a similar derived object.  The suggested .derive() function seemed simplest.


- Shawn

 
(Selfhost 7908)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110124/826da5b5/attachment-0001.html>

More information about the es-discuss mailing list