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