So you are saying, if library developer wanted to keep his library flexible
and avoid:
var region = loc.region;
if (region === undefined && allowInferrence) {
region = loc.inferredRegion;
} else {
return error; // or fallback gracefully.
}
blocks of code, he could let end developer pass constructed LocaleInfo
object (with inferData set to true or false), or just a flag and then
construct LocaleInfo object. Library code would then look like:
var region = loc.region;
if (region === undefined && !allowInference) {
return error; // or fallback gracefully.
} else if (region === undefined && allowInference) {
// This case shouldn't happen?
}
In both cases library (black box) writer would need to do defensive checks
in order to provide robust library, and this boils down to which approach
looks better, and requires less code. I don't think either approach limits
black box author in anyway.
We could write a non-nonsense library and see what looks/works better?
24. јануар 2011. 16.38, Shawn Steele <shawn.ste...@microsoft.com> је
написао/ла:
> I agree, but I don’t think that’s necessarily clear to the blackbox
> library. Additionally the “inferredRegion” seems a bit harder to use, so I
> think maybe the blackbox would lean towards “region” even if
> “inferredRegion” might be acceptable.
>
>
>
> And then the “black box” library has to make the decision. If this is a
> worker library, that decision may not be appropriate for the library to
> make. If the decision is appropriate for the caller to make instead, then
> it’s tricky for the library to do the right thing. If the black box library
> thinks that inferred is acceptable, then it calls “inferredRegion.” But in
> caller’s context, if that isn’t acceptable, the caller would have a problem
> “correcting” that internal blackbox behavior.
>
>
>
> OTOH: With “my” approach, if the caller specified the behavior, then the
> blackbox would get error conditions if they tried to get “region” and it
> wasn’t allowed. So it could err. And if the blackbox really needed to be
> making the decision, then it still could.
>
>
>
> -Shawn
>
>
>
> *From:* es-discuss-boun...@mozilla.org [mailto:
> es-discuss-boun...@mozilla.org] *On Behalf Of *Nebojša Ciric
> *Sent:* Monday, January 24, 2011 4:30 PM
> *To:* Mark Davis ☕
> *Cc:* Shawn Steele; es-discuss@mozilla.org
> *Subject:* Re: i18n objects
>
>
>
> I think we are missing couple details here.
>
>
>
> In case user provides the region when constructing LocaleInfo, both .region
> and .inferredRegion would be the same (i.e. there is nothing to infer).
>
> ---------------------------------------------------
>
> data provided | US | nothing
>
> ---------------------------------------------------
>
> .region | US | undefined
>
> .inferredRegion | US | US
>
> ---------------------------------------------------
>
>
>
> If one is willing to use inferred data then he can just get the value of
> inferred property (or call a function). If one is not willing, he should
> always look into .region property.
>
>
>
> This approach duplicates number of properties, but eliminates inferrData
> constructor option, and isInferred() method.
>
>
>
> 24. јануар 2011. 16.09, Mark Davis ☕ <m...@macchiato.com> је написао/ла:
>
> 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 <shawn.ste...@microsoft.com>
> 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:* mark.edward.da...@gmail.com [mailto:mark.edward.da...@gmail.com] *On
> Behalf Of *Mark Davis ?
> *Sent:* Monday, January 24, 2011 3:41 PM
> *To:* Shawn Steele
> *Cc:* es-discuss@mozilla.org
> *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 <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
>
>
>
>
> --
> Nebojša Ćirić
>
--
Nebojša Ćirić
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
