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 - Shawn http://blogs.msdn.com/shawnste (Selfhost 7908)
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
