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. On Jan 24, 2011, at 12:39 PM, Shawn Steele wrote: > 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:c...@google.com] > Sent: Monday, January 24, 2011 11:32 AM > To: Shawn Steele > Cc: es-discuss@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.ste...@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 > > > http://blogs.msdn.com/shawnste > (Selfhost 7908) > > > _______________________________________________ > 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
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
