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 <[email protected]> је написао/ла: > 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 [[email protected]] > *Sent:* Tuesday, January 25, 2011 10:09 PM > *To:* Shawn Steele; Mark Davis ☕ > *Cc:* [email protected]; 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:[email protected]] > *Sent:* Monday, January 24, 2011 3:53 PM > *To:* Mark Davis ☕ > *Cc:* [email protected] > *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:* [email protected] [mailto:[email protected]] *On > Behalf Of *Mark Davis ? > *Sent:* Monday, January 24, 2011 3:41 PM > *To:* Shawn Steele > *Cc:* [email protected] > *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 <[email protected]> > 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 > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > > -- Nebojša Ćirić
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
