I made quick update - could you take a look if I captured the essentials (there are 2 proposals)?
http://wiki.ecmascript.org/doku.php?id=strawman:i18n_api#proposal_1_shawns I tried to get examples to show best and worst cases for both approaches - update if you can do worse :). 26. јануар 2011. 13.54, Shawn Steele <shawn.ste...@microsoft.com> је написао/ла: > Ah, well. Hmmm. I was sort of assuming the caller would care if the data > was valid and that the callee wouldn’t be making that kind of decision. > > > > If we went with “infer-by-default”, then your scenario wouldn’t happen (S) > unless the app really didn’t want inferring. In which case your workaround > is the wrong thing to do (I’d think). > > > > I really don’t want to double the surface, but I see your point about > changing from uninferred to inferred. > > > > -Shawn > > > > *From:* mark.edward.da...@gmail.com [mailto:mark.edward.da...@gmail.com] *On > Behalf Of *Mark Davis ? > *Sent:* Wednesday, January 26, 2011 1:51 PM > *To:* Shawn Steele > *Cc:* Nebojša Ćirić; Phillips, Addison; Gillam, Richard; > es-discuss@mozilla.org > *Subject:* Re: i18n objects > > > > Your last message was illustrative. > > > > From our perspective, the mainline service APIs (currency formatting, > collation, etc.) should always return the best possible answer, with some > way to determine whether or not the data was inferred or not in case someone > cares (which is important, but definitely the lower-runner case). So > writing from the point of view of implementing a service, we'll need to get > the the best currency from a LocaleInfo. What your proposal forces us to do > is something like Alternative S below, instead of Alternative M: > > > > *Alternative S:* > > > > theCurrency = inputLocaleInfo.region; > > // if we didn't get one, then the creator of the inputLocaleInfo set > infer:false, so we have to work around that > > if (theCurrency == null) { > > myInputLocaleInfo = new LocalInfo({localeInfo:inputLocaleInfo, > infer:true); > > theCurrency = myInputLocaleInfo.region; > inferredCurrency = true; > > } else { > > inferredCurrency = false; > > } > > > > > > *Alternative M:* > > > > theCurrency = inputLocaleInfo.inferCurrency; > > inferredCurrency = inputLocaleInfo.region != null; > > > > > > I think having a phone call will help to understand all the perspectives on > the issue. > > > > Mark > > *— Il meglio è l’inimico del bene —* > > On Wed, Jan 26, 2011 at 13:27, Shawn Steele <shawn.ste...@microsoft.com> > wrote: > > I’m sorry, I missed part of the thread. I’d be happy if Nebojša would > update the doc, and I’d be happy to participate in a call. (I can’t update > it that fast). > > > > Anytime is OK for me. > > > > -Shawn > > > > *From:* es-discuss-boun...@mozilla.org [mailto: > es-discuss-boun...@mozilla.org] *On Behalf Of *Nebojša Ciric > > > *Sent:* Wednesday, January 26, 2011 1:07 PM > *To:* Phillips, Addison > > *Cc:* Gillam, Richard; Shawn Steele; es-discuss@mozilla.org > *Subject:* Re: i18n objects > > > > The es strawman was not updated with the recent discussion. I can do that > before the call, and put both versions there. Shawn could check if my > representation matches his proposal... > > 26. јануар 2011. 13.03, Phillips, Addison <addi...@lab126.com> је > написао/ла: > > Sure. > > > > Did someone update the docs? Where can we get at them? > > > > Thanks, > > > > Addison > > > > Addison Phillips > > Globalization Architect (Lab126) > > Chair (W3C I18N, IETF IRI WGs) > > > > Internationalization is not a feature. > > It is an architecture. > > > > *From:* Nebojša Ćirić [mailto:c...@google.com] > *Sent:* Wednesday, January 26, 2011 1:02 PM > *To:* Shawn Steele > *Cc:* Phillips, Addison; Mark Davis ☕; Gillam, Richard; > es-discuss@mozilla.org > *Subject:* Re: i18n objects > > > > Would people be interested in a teleconference call, say Friday to discuss > this further (in case posting to the list doesn't resolve conflicts soon)? > > I can make the arrangements... > > 26. јануар 2011. 01.35, Shawn Steele <shawn.ste...@microsoft.com> је > написао/ла: > > 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 [addi...@lab126.com] > *Sent:* Tuesday, January 25, 2011 10:09 PM > *To:* Shawn Steele; Mark Davis ☕ > *Cc:* es-discuss@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.ste...@microsoft.com] > *Sent:* Monday, January 24, 2011 3:53 PM > *To:* Mark Davis ☕ > *Cc:* es-discuss@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.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 > > > -- Nebojša Ćirić
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
