i18n objects

Shawn Steele Shawn.Steele at microsoft.com
Wed Jan 26 01:35:51 PST 2011


A "common" pattern is to require some sort of data (like date format), even if you don't have enough information.  The missing-data-so-end-up-at-root is a similar sort of scenario.  "Many" applications have the information they provide.  If we can't get a value from that, they're sunk because they cannot get more specific.



I'm not saying that's the best thing for all apps, or even that all apps use it right, but we find far more developer errors when we're not "helpful" enough than from cases where we were over-helpful.



My problems with the inferred/not inferred pattern are:



1) that the function actually doing the work may not be the function that "knows" if the data should be inferred or not.  That may be the caller.  So then all worker functions have to use the inferred form, which seems awkward.  Yes, I'm presuming the caller knows what they're doing, but I think that's pretty safe.



2) Ok, so we have "both" forms.  Then I call the base form, and it fails because it had bogus data.  That's WAY too late, if this scenario concerns me, then I need to test up-front so that I don't have to do heavy error checking on every call.  Or else the non-inferred functions need to throw.



3) My other problem is that it seems to unnecessarily duplicate the surface that has to be tested.



var loc = new LocaleInfo({localeName:"en"});

var dtf = new DateTimeFormat({locale:loc});

dtf.Format(); //  Should this require a "inferredFormat" ?  That seems really heavy, but en-US and en-anywhere else have different default values.



It's trivial for the caller (or the callee) to see if scary stuff is being inferred, so I don't see how multiple APIs help.  It's much better to validate inputs BEFORE calling the format, than to cross your fingers that Format will find problems for you.


-Shawn

 
http://blogs.msdn.com/shawnste

________________________________
From: Phillips, Addison [addison at lab126.com]
Sent: Tuesday, January 25, 2011 10:09 PM
To: Shawn Steele; Mark Davis ☕
Cc: es-discuss at mozilla.org; Gillam, Richard
Subject: RE: i18n objects

Hi,

I’ve been following this thread carefully this week, thinking to chime in here or there (but not needing to so far).

Is there a place where updated docs are accumulating? We’re nearly done with our squirrelfish implementation and I’m getting the feeling that it’s becoming non-standard ;-). Also, we’re noticing some gaps in the earlier docs. I want to see if they’ve been addressed or if I should comment instead.

WRT the current discussion, I think the problem for me falls between “explicit BCP47 fields” (what I’ve tended to call the “gross locale identifier”), which I’m pretty sure I don’t want automagically populated, and “implicit fields” (i.e. the ones you’d specify using the extension). The implicit fields I kind of expect to have a default setting—if I give you “de”, there should be a default collation, currency, calendar, and such. And maybe the Latin script (Suppress-Script says so). But inferring “de-DE” seems ambitious. Maybe for German it’s not so bad, but many times I don’t want inferences about region to be foisted upon me.

As a result, I’m more in favor of Mark’s solution (you can get an inferred value, but you have to call for it; in most cases, you get null for unset fields). But would that be for all fields? I’d rather that not be the case.

Just a thought.

Addison

Addison Phillips
Globalization Architect (Lab126)
Chair (W3C I18N, IETF IRI WGs)

Internationalization is not a feature.
It is an architecture.

From: Shawn Steele [mailto:Shawn.Steele at microsoft.com]
Sent: Monday, January 24, 2011 3:53 PM
To: Mark Davis ☕
Cc: es-discuss at mozilla.org
Subject: RE: i18n objects

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.davis at gmail.com [mailto:mark.edward.davis at gmail.com] On Behalf Of Mark Davis ?
Sent: Monday, January 24, 2011 3:41 PM
To: Shawn Steele
Cc: es-discuss at 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.Steele at microsoft.com<mailto:Shawn.Steele at 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 at mozilla.org<mailto: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/20110126/468c0cfd/attachment-0001.html>


More information about the es-discuss mailing list