As stated before, I think that this approach is more error prone; that it would be better to explicitly call the other function. Here would be the difference between the two alternatives for the API: A and B, under the two common scenarios:
*Scenario 1 "I don't care"* A. x = myLocaleInfo.region; B. x = myLocaleInfo.inferRegion(); *Scenario 2. "I only want explicit region"* A. x = myLocaleInfo.hasInferredRegion ? undefined : myLocaleInfo.region; B. x = myLocaleInfo.region(); I find the B approach simpler and clearer, and we don't have to have an extra input parameter. Mark *— Il meglio è l’inimico del bene —* On Mon, Jan 24, 2011 at 10:25, Shawn Steele <shawn.ste...@microsoft.com>wrote: > 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 > >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
