As promised, more verbose feedback for the Globalization API. My general
feeling is that the API is overly verbose for what it's doing. I'll
state my bias up front: I'm not a fan of introducing a bunch of new
types to handle formatting. I'd much rather have additional methods that
perform formatting on existing objects. My feedback is mostly about
eliminating the new constructors - which has an added bonus of
eliminating the Globalization namespace because there would be only one
constructor left: Collator.
1. LocaleList
I'm not sure why this type is necessary. I don't believe that locale
resolution is an expensive operation, and even if it is, I'd expect the
implementation to cache the results of such resolution for later use.
I'd just leave this as an internal construct and instruct developers to
use arrays all the time.
2. supportedLocalesOf
I find this method name strange - I've read it several times and am
still not sure I fully understand what it does. Perhaps
"getSupportedLocales()" is a better name for this method? (I always
prefer methods begin with verbs.)
3. NumberFormat
Number formatting seems simple enough that it could just be added as a
series of methods on Number.prototype. The three types of formatting
(currency, decimal, percent) could each have their own method. Currency
formatting has relatively few options to specify, so it's method can be:
/*
* Formats the number as if it were currency
* @param code Currency code, e.g., "EUR"
* @param type (Optional) The way to format the currency code,
"code", "symbol" (default),
* @param locales - (Optional) Array of locales to use.
*/
Number.prototype.toCurrencyString = function(code, type, locales) {
...
};
var num = 500;
console.log(num.toCurrencyCode("EUR", "code")); //"EUR 500.00"
Decimal and percent formatting options are slightly different in that
they include significant digits options. For that, I prefer to use a
formatting string rather than the multitude of optional properties as
currently defined (see
http://www.exampledepot.com/egs/java.text/FormatNum.html). The
formatting string indicates must-have digits as 0 and optional digits as
#, allowing you to very succinctly specify how you want your number to
be output. For example:
/*
* Formats the number as a decimal string.
* @param format Format string indicating max/min significant digits
* @param locales (Optional) Array of locales to use.
*/
Number.prototype.toDecimalString = function(format, locales){
...
};
/*
* Formats the number as a percent string.
* @param format Format string indicating max/min significant digits
* @param locales (Optional) Array of locales to use.
*/
Number.prototype.toPercentString = function(format, locales){
...
};
var num = 1234.567;
console.log(numtoDecimalString("000##.##")); "01234.57"
4. DateTimeFormat
As with NumberFormat, it seems like this could more succinctly be
implemented as a method on Date.prototype. As its easiest:
/*
* Format a date
* @param options The already-defined options for DateTimeFormat
* @param locales (Optional) Array of locales to use.
*/
Date.prototype.toFormatString = function(options, locales){
...
};
In an ideal world, I'd like to see options overloaded so it can be an
options object as specified now or a formatting string. I understand
that there was a sentiment against formatting strings due to their
limitations and edge case errors. However, I'd like to point out that
any internationalized web application is highly likely to already be
using formatting strings for dates, since this is pretty much how every
other language handles date formatting. That means supporting format
strings in JavaScript would allow application developers to reuse the
settings they already have. As it stands now, you'd need to create two
different ways of formatting dates for a web app: one for your
server-side language and one for your client-side language (until the
day everything is running on Node.js, of course). I'd prefer my
client-side code to reuse settings and configuration that the
server-side code uses, otherwise I end up with two very different pieces
of code doing the exact same thing, and there be dragons.
-Nicholas
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
