Thanks for the clarification. Let's see what we can do to reduce object creation.
At the TC 39 meeting, we seemed to have agreement that it's OK for the Globalization specification to respecify the existing *Locale* methods, as proposed here: http://wiki.ecmascript.org/doku.php?id=strawman:globalization-integration With that, the first example would become: var price = 300, currency = price.toLocaleString(localeList, {style: "currency", currency: "USD"}); NumberFormat supports three styles, with "decimal" being the default, so we could reduce the need for options objects by adding functions toLocaleCurrencyString and toLocalePercentString, specified (but not implemented) as: Number.prototype.toLocaleCurrencyString = function(localeList, currency, options) { var myOptions = Object.create(options, {style: "currency", currency: currency}); return (new Globalization.NumberFormat(localeList, myOptions)).format(this); } This would let you use: var currency = price.toLocaleCurrencyString(localeList, "USD"); Is that a good trade-off, introducing new functions for common use cases in order to avoid object creation? Note that if you format lots of currency strings, you're probably better off performance-wise to openly create the NumberFormat object and reuse it, rather than having the implementation look for it in its cache based on your parameters each time around. The second example would be: var now = new Date(), pretty = now.toLocaleDateString(localeList); assuming that you can live with the locale's default representation for day and month (some will pad to two digits, others won't). If you do need padding to two digits, it would currently be: var pretty = now.toLocaleDateString(localeList, {year: "numeric", month: "2-digit", day: "2-digit"}); So much on the current situation - I'm looking forward to your feedback! Thanks, Norbert On Nov 18, 2011, at 11:26 , Nicholas Zakas wrote: > As part of the group that said the API is too Java-like, I'd like to > clarify. "Java-like" to me means that you need to create one or more > objects that are only kept around for a short period of time to > perform a single task. For example, if I already have a Number object > and want to format that number as currency, I'd expect to be able to > do something like this: > > var price = 300, > currency = price.toCurrencyString("USD"); > > Likewise for formatting dates: > > var now = new Date(), > pretty = now.toFormatString("mm/dd/yyyy"); > > Or some such thing. Realizing, of course, the discussion around > wanting to avoid formatting strings. > > I'll be writing up a longer piece of feedback this weekend. > > -N > > > > On Thu, Nov 17, 2011 at 5:29 PM, Brendan Eich <bren...@mozilla.com> wrote: >> On Nov 17, 2011, at 2:22 PM, Nebojša Ćirić wrote: >>> >>> Q. API is too Java like. Use shorthand to invoke formatters. >>> A. I would like to hear proposals on how to make it more JS like. Adding >>> shorthand syntax is easy, but most of TC39 members were against having 2 >>> ways of doing things first time we proposed it. >>> Here is an example of current API in action - http://pastebin.com/pjfdKYss >> >> Would converting constructors into factories help make API less Java like? >> For example, instead of: >> var dtf = new DateTimeFormat(...); >> we have >> var dtf = createDateTimeFormat(...); >> >> No, that's worse. Constructors used with 'new' are ok if you really need a >> new object to do something. >> What's JS-esque is to use a *function* when you don't need to allocate an >> object just to call one method on it, then let it become garbage to collect. >> Also being able to use the function as a first-class value (pass it around >> as a funarg, stick it on some other object, decorate it with ad-hoc >> properties). >> /be _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
