Intent of i18n "inferred" values
I guess we should throw when creating an object (should .derive() throw then too?), but not when returning a property (say .region).
- јануар 2011. 10.11, Shawn Steele <Shawn.Steele at microsoft.com> је написао/ла:
I’m not sure what the property/object difference is? Is it .region (an object) or .regionName (a string)? I’d been assuming we’d return objects. There shouldn’t be errors constructing the object itself, unless somehow you provided very invalid parameters (like inferDetals: “fred” instead of true or false).
-Shawn
From: Nebojša Ćirić [mailto:cira at google.com] Sent: Monday, January 24, 2011 11:32 AM To: Shawn Steele Cc: es-discuss at mozilla.org Subject: Re: Intent of i18n "inferred" values
I guess we should throw when creating an object (should .derive() throw then too?), but not when returning a property (say .region). 24. јануар 2011. 10.11, Shawn Steele <Shawn.Steele at microsoft.com<mailto:Shawn.Steele at microsoft.com>> је написао/ла:
My understanding of “inferred” values for the LocaleInfo object is that, when inferred is allowed/used, that values which are not explicitly specified in the constructor (eg: calendar), will be inferred as best as possible from the other inputs.
For example: If I construct it with: var myLocale = new LocaleInfo( { localeName: “en-US”, inferDetails: “true” } ); then it could return a Gregorian calendar for var cal = myLocale.calendar;
And, if it wasn’t obvious, it could fall back to defaults: var klingon = new LocaleInfo( { localeName: “tlh”, inferDetails: “true” } ); var cal = klingon.calendar; // ends up at Gregorian because there’s no real data here.
If inferred is false, then should it fail by returning undefined or throw an error? var klingon = new LocaleInfo( { localeName: “tlh”, inferDetails: “false” } ); var cal = klingon.calendar; // throw or undefined?
Throwing seems a bit heavy to me, however it also seems a bit “safer.” In the i18n meeting we’d said that errors would throw, however testing for whether or not a valid value was available seems to me more like a normal condition than an exception.
- Shawn
blogs.msdn.com/shawnste (Selfhost 7908)
There is no particular reason an object couldn't have both .region and .regionName properties. However, .region.name might provide the same result as regionName. In general, you need to think about what interface makes sense for the object you are defining. Is there ever a situation where perhaps a .regionName is available but .region isn't? That would be a good reason to have both properties.
The most common convention in JavaScript is to use undefined to indicate that a value has not been set or is otherwise unavailable rather than throwing an exception when accessed. The latter requires more work in both the implementation of the object and on the part of the code that is accessing the property.
My understanding of “inferred” values for the LocaleInfo object is that, when inferred is allowed/used, that values which are not explicitly specified in the constructor (eg: calendar), will be inferred as best as possible from the other inputs.
For example: If I construct it with: var myLocale = new LocaleInfo( { localeName: “en-US”, inferDetails: “true” } ); then it could return a Gregorian calendar for var cal = myLocale.calendar;
And, if it wasn’t obvious, it could fall back to defaults: var klingon = new LocaleInfo( { localeName: “tlh”, inferDetails: “true” } ); var cal = klingon.calendar; // ends up at Gregorian because there’s no real data here.
If inferred is false, then should it fail by returning undefined or throw an error? var klingon = new LocaleInfo( { localeName: “tlh”, inferDetails: “false” } ); var cal = klingon.calendar; // throw or undefined?
Throwing seems a bit heavy to me, however it also seems a bit “safer.” In the i18n meeting we’d said that errors would throw, however testing for whether or not a valid value was available seems to me more like a normal condition than an exception.
blogs.msdn.com/shawnste (Selfhost 7908)
My understanding of “inferred” values for the LocaleInfo object is that, when inferred is allowed/used, that values which are not explicitly specified in the constructor (eg: calendar), will be inferred as best as possible from the other inputs. For example: If I construct it with: var myLocale = new LocaleInfo( { localeName: “en-US”, inferDetails: “true” } ); then it could return a Gregorian calendar for var cal = myLocale.calendar; And, if it wasn’t obvious, it could fall back to defaults: var klingon = new LocaleInfo( { localeName: “tlh”, inferDetails: “true” } ); var cal = klingon.calendar; // ends up at Gregorian because there’s no real data here. If inferred is false, then should it fail by returning undefined or throw an error? var klingon = new LocaleInfo( { localeName: “tlh”, inferDetails: “false” } ); var cal = klingon.calendar; // throw or undefined? Throwing seems a bit heavy to me, however it also seems a bit “safer.” In the i18n meeting we’d said that errors would throw, however testing for whether or not a valid value was available seems to me more like a normal condition than an exception. - Shawn http://blogs.msdn.com/shawnste (Selfhost 7908) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110124/f4bd463a/attachment.html>