2nd day meeting comments on the latest i18n API proposal

Mark Davis ☕ mark at macchiato.com
Fri Jan 21 16:01:25 PST 2011


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.Steele at 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-bounces at mozilla.org [mailto:
> es-discuss-bounces at mozilla.org] *On Behalf Of *Mark Davis ?
> *Sent:* Friday, January 21, 2011 12:44 PM
> *To:* Axel Hecht
> *Cc:* Derek Murman; es-discuss at 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 <axel at 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 <petercon at microsoft.com
>
> <mailto:petercon at 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:cira at google.com <mailto:cira at google.com>]
>
>
>    *Sent:* Wednesday, January 19, 2011 5:02 PM
>
>    *To:* es-discuss at mozilla.org <mailto:es-discuss at 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 at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110121/7834353b/attachment.html>


More information about the es-discuss mailing list