The “black box” library has no clue if the person calling the black box wants me to infer or not, that’s up to the caller. However the black box would have to choose which API to call. With inferred being a state of LocaleInfo though, then it’s somewhat easy for the caller to ensure that it creates it the way it intends.
-Shawn From: [email protected] [mailto:[email protected]] On Behalf Of Mark Davis ? Sent: Monday, January 24, 2011 4:09 PM To: Shawn Steele Cc: [email protected] Subject: Re: i18n objects I don't understand. * If you want the explicit value, you call .region. * NB, the value will be undefined iff it is not set explicitly. * If you want the (possibly) inferred value, you call .inferRegion(). * NB, the value is never undefined. What is the problem? Mark — Il meglio è l’inimico del bene — On Mon, Jan 24, 2011 at 15:53, Shawn Steele <[email protected]<mailto:[email protected]>> wrote: But assume I have a “black-box” API that prints a report or something. If the caller correctly sets the LocaleInfo() for inferred or not inferred, it can call BlackBox(myLocale). However now myLocale has to call either .region or .inferredRegion, depending on whether or not it’s inferred. But the “black box” may not have a clue whether inferred is correct (or not). IMO it’s better to let the LocaleInfo object behave however the caller wants it to behave and let BlackBox assume that the caller’s using it right. IF the blackbox really cares, it can still check, but, IMO, that’s very uncommon. From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Mark Davis ? Sent: Monday, January 24, 2011 3:41 PM To: Shawn Steele Cc: [email protected]<mailto:[email protected]> Subject: Re: i18n objects 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 <[email protected]<mailto:[email protected]>> 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 [email protected]<mailto:[email protected]> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
