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.
· 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss