The problem I see is that if I hand you a LocaleInfo, and there is only one
API to get the region, then it (in your words) **is easy** to "accidentally
make the wrong choice, or not realize they need to make a choice".
- x.region may be an explicit value or may be computed: I have to call
some other API to find out.
If we have a separate API, then I, the developer, have it clearly in front
of me what choice I am to to make, and it **is harder** to accidentally make
the wrong choice, &c.
- x.region is always an explicit value
- x.inferRegion() is computed if there is no explicit value.
Mark
*— Il meglio è l’inimico del bene —*
On Fri, Jan 21, 2011 at 14:04, Shawn Steele <shawn.ste...@microsoft.com>wrote:
> IMO that’s going overboard in the other direction J It’d be nice to find
> some middle ground.
>
>
>
> Sometimes inferring can be very bad. Sometimes it can be very good. The
> problem isn’t that one is “right” or “wrong” for all apps, but rather that
> it might be simple for developers to accidentally make the wrong choice, or
> not realize they need to make a choice. If I need to infer, it should be
> easy to get a fully-inferred LocaleInfo. If I don’t need to infer, then it
> should be easy to avoid inferring for LocaleInfo.
>
>
>
> -Shawn
>
>
>
> *From:* es-discuss-boun...@mozilla.org [mailto:
> es-discuss-boun...@mozilla.org] *On Behalf Of *Mark Davis ?
> *Sent:* Friday, January 21, 2011 12:44 PM
> *To:* Axel Hecht
> *Cc:* Derek Murman; es-discuss@mozilla.org
> *Subject:* Re: 2nd day meeting comments on the latest i18n API proposal
>
>
>
> I would actually rather not have it be a construction argument, because it
> is easier for people to make mistakes that way.
>
>
>
> When I look this over, there are relatively few fields that need this. So
> what about having API like:
>
>
>
> // get an explicitly-set region, or null if there was no region parameter
> in the constructor.
>
>
>
> region1 = myLocaleInfo.region;
>
>
>
> // gets myLocaleInfo.region if not null
>
> // otherwise infers the region from other information in the LocaleInfo.
>
>
>
> aRegion = myLocaleInfo.inferRegion();
>
>
>
>
>
>
>
> The ones where this would be done would be:
>
>
>
> inferBaseLanguage()
>
> inferScript()
>
> inferRegion()
>
> inferCurrency()
>
> // later: inferTimeZone()
>
>
>
>
>
> Mark
>
> *— Il meglio è l’inimico del bene —*
>
> On Fri, Jan 21, 2011 at 11:19, Axel Hecht <a...@mozilla.com> wrote:
>
> I for one am very much against setting inferValues to true by default.
> That's just obfuscating i18n bugs, and I think we should design our APIs so
> that it's easy to get it right. Shooting yourself in the foot should be
> hard, if at all possible.
>
> Axel
>
>
>
> On 21.01.11 09:39, Nebojša Ćirić wrote:
>
> If we were to go with loc.options, I would define it as having only
> items that were explicitly listed when object was constructed. So:
>
> var loc = new LocaleInfo({'calendar':'hijri', 'lang': 'en-US',
> 'inferValues': true});
>
> loc.options would contain:
> loc.options.calendar - hijri
> loc.options.lang - en-US
> loc.options.inferValues - true
>
> loc object would have:
> loc.currency
> loc.lang
> loc.inferValues
> loc.calendar (maybe)
> loc.region
> ...
>
> One could implement isInferred(x) method like this:
> function isInferred(x) {
> if (x in loc.options && x in loc && loc.options.x === x)
> return false;
> else
> return true;
>
> There would be some duplication of data with this approach, but it would
> give us easy way to check what were the options we passed in when
> constructed the object, and to detect if the value was inferred or not.
>
> Btw. I think we agreed to have inferreValues set to true by default.
>
> 20. јануар 2011. 22.15, Peter Constable <peter...@microsoft.com
>
> <mailto:peter...@microsoft.com>> је написао/ла:
>
>
>
> We had talked about having an option on the LocaleInfo constructor
> to control whether values not explicitly set could be inferred. E.g.
>
> var loc = new LocaleInfo({lang:”en-US”, inferValues:true});
>
> var curr = loc.currency; // is USD
>
> With the approach of having .derive() methods, then the constructed
> clone is exactly the same. So, for instance,
>
> var loc2 = loc.derive({calendar:hijri});
>
> if (loc2.isInferred(currency)) // is true
>
> Considering this other approach, when I get opt2…
>
> var opt2 = loc.options;
>
> what all does opt2 include? Does it include only options that were
> explicitly passed in when loc was constructed, or does it include
> specific values for all LocaleInfo properties that could be set as
> options and could be inferred? If the latter, does it reflect that
> most of them were inferred?
>
> Peter
>
> *From:*Nebojša Ćirić [mailto:c...@google.com <mailto:c...@google.com>]
>
>
> *Sent:* Wednesday, January 19, 2011 5:02 PM
>
> *To:* es-discuss@mozilla.org <mailto:es-discuss@mozilla.org>
>
>
> *Subject:* 2nd day meeting comments on the latest i18n API proposal
>
> Eric proposed to remove the derive method from all API objects and
> do something like this:
>
> var loc = new LocaleInfo({....}); // {...} are the options we
> construct LocaleInfo object with.
>
> var opt2 = loc.options; // This returns a copy of options from loc
> object.
>
> opt2.currency = "USD";
>
> var loc2 = new LocaleInfo(opt2);
>
> This approach yields the same result with more code, but it's a more
> in sync with how people expect JavaScript API to work.
>
> In this case LocaleInfo needs to have options property that holds
> original inputs. This approach could also help with inferred values
> - one can compare options with actual property and see if they are
> the same.
>
> var loc = LocaleInfo({currency: 'USD'});
>
> if (loc.options.currency == loc.currency) ...
>
> --
> Nebojša Ćirić
>
>
>
>
> --
> Nebojša Ćirić
>
>
> _______________________________________________
> 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
>
>
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
