Nicholas, Andrea, Rick, Thanks for your feedback. A few replies:
Why DateTimeFormat and NumberFormat as separate object types rather than methods on Date.prototype and Number.prototype: I suspect Conway's Law played a bit of a role here - an ad hoc team was chartered by TC 39 with developing a separate standard, and so it did. I hope that eventually we'll be able to tie the results back into core language classes, and have written up a strawman for that (so far just my own musings): http://wiki.ecmascript.org/doku.php?id=strawman:globalization-integration Having separate objects available however is useful at times because it lets the application find out about the results of language negotiation, and to avoid the cost of redoing negotiation and setup for each format call. Verbosity of object literal specification in date format: Personally, I agree that the current spec draft is a bit complicated; I once proposed a slightly simpler variant: http://norbertlindenberg.com/ecmascript/internationalization-formats.html#DateTimeFormat A simple format pattern like "hh:mm:ss" however doesn't give us enough information to generate properly localized results: Does the absence of an am/pm indicator mean you always want 24-hour time, or is that just the preference of your language, and in others it should be 12-hour time with am/pm? Should the Chinese version be plain numeric (12:34:56) or with the characters for hour/minute/second (12时34分56秒)? Libraries using such patterns usually expect applications to bring along localized patterns - we instead want to leverage the information about hundreds of languages that the internationalization libraries of modern operating systems already include. ICU has "skeletons", which are less language dependent than patterns, although still not entirely language independent, and are mapped to patterns using significant amounts of magic: http://unicode.org/reports/tr35/#Date_Format_Patterns If you have ideas on how to simplify the API without requiring applications to provide localized format patterns, I'd love to hear them. Thanks, Norbert On Oct 29, 2011, at 7:26 , Rick Waldron wrote: > Also +1 to Nicholas points > > On the whole, the proposal is very verbose - I'm not sure how much more clear > the web development community has to be about this - they don't want to type > long Java-esque constructor names. Look at any popular library - the best > ones are those that create simple, concise syntax. This should be the first > priority of all new APIs. > > Rick > > > > On Sat, Oct 29, 2011 at 5:37 AM, Andrea Giammarchi > <andrea.giammar...@gmail.com> wrote: > I think the main reason to have a FormatComponent is to give each > DateTimeFormat instance a configuration state so that once you define it you > can "format" it automatically any time you print it out. > > Said that, I am familiar as example with gmdate() PHP function or similar > "string syntax" as it could be "%.2f" for numbers and I agree these are more > handy and more "JavaScripysh" so that if ES.next won't have them, many > developers will try to add these shortcuts into Data.prototype object with > {writable:false,enumerable:false,configurable:false} descriptor. > > This underlines one more time too much abstraction or engineering may result > into less practical usage for daily basis tasks. > > +1 for Nicholas idea > > > On Fri, Oct 28, 2011 at 9:35 PM, Nicholas Zakas <standa...@nczconsulting.com> > wrote: > I've just been reviewing the internationalization spec: > https://docs.google.com/document/pub?id=1rsUxJQ03Ql6o3bh6RN7J81dtYZXE7OVsdQBw_h5ASnM&ndplr=1&pli=1 > > First off - hooray! This is long, long, long overdue. > > The biggest question I have is with regards to the DateTimeFormat and > NumberFormat. I'm wondering why you've chosen to have these as separate > object types instead of adding methods onto Date.prototype and > Number.prototype, respectively? It doesn't seem like having these as separate > objects provides much more value since they mostly just use their format() > methods. > > Smaller question is on specifying the format. The object literal > specification of the format seems overly verbose for dates, and perhaps also > for numbers. I'd really love to be able to do something like this: > > var now = Date(); > console.log(now.format("hh:mm:ss")); > > var price = 1010; > console.log(price.format("#,###")); > > I'd hypothesize that most programmers are familiar with this type of > date/numeric formatting strings as they are in use in other languages. I'd > much prefer being able to use a formatting string vs. an object literal with > multiple properties that aren't very transparent as to their consequence. > > Just to emphasize: I really like the functionality in the spec, it just seems > more Java-like and verbose than what's in JavaScript right now, and I'm > wondering if there are ways to change that. > > Thanks, > Nicholas _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
