i18n API implementation issues
Allen Wirfs-Brock
allen at wirfs-brock.com
Wed May 18 16:08:38 PDT 2011
On May 18, 2011, at 3:35 PM, Nebojša Ćirić wrote:
>> 4. Should we rename LocaleInfo.collator()/numberFormat()/dateTimeFormat() into LocaleInfo.createCollator()...? It makes it clear we are creating new object.
>
> The methods on the LocaleInfo constructor or are they really LocaleInfo.prototype methods. In other words are the results derived from a specific LocaleInfo instance or is the result some sort of global value that is independent of the instances. If the latter, why are they associated with the LocaleInfo constructor?
>
> They are prototypes:
>
> LocaleInfo.prototype.collator()
>
> I propose
>
> LocaleInfo.prototype.createCollator()
>
> since they actually create a new LocaleInfo.Collator (or DateTimeFormat or NumberFormat) objects based on that locale info.
>
It could go either way and there isn't a lot of relevant precedent in the ES built-in libraries to guide this. If it is essential an characteristic that a new object is being created I personally would be inclined to put something in the name to indicate that. Personally I might use newXXX rather than createXXX. The other possibility is that you could make them be constructor functions so you would say:
var myDtf = new myLocale.DateTimeFormat(myOptions);
Since any native ES function can be used as a constructor (and will even do the right thing if it is carefully code with that possibility in mind) I guess that might argue for the non-imperative naming, particularly if it starts with an upper case. Then either the above or
var myDtf = myLocale.DateTimeFormat(myOptions);
would be equivalent. I think they both read fine.
Allen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110518/074e5411/attachment.html>
More information about the es-discuss
mailing list