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]>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]] *On
> Behalf Of *Mark Davis ?
> *Sent:* Monday, January 24, 2011 3:41 PM
> *To:* Shawn Steele
> *Cc:* [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]>
> 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]
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
