Polish existing skeleton API.

Polish existing skeleton API.
TBR.
Committed: https://code.google.com/p/dart/source/detail?r=8226

[Emily Fortuna, 2012-06-02 05:49:26]

(this cleans up what we originally had. Our new changes can be added in the
future.)

[Alan Knight, 2012-06-04 19:58:37]

https://chromiumcodereview.appspot.com/10506006/diff/4001/lib/i18n/date_time_...
File lib/i18n/date_time_format.dart (right):

https://chromiumcodereview.appspot.com/10506006/diff/4001/lib/i18n/date_time_...
lib/i18n/date_time_format.dart:6: * DateTimeFormat is for formatting and parsing
dates in a locale-sensitive
I'd called it DateFormat because the objects it operates on are Dates, and we
don't have either Time or DateTime objects. And it's shorter.

https://chromiumcodereview.appspot.com/10506006/diff/4001/lib/i18n/date_time_...
lib/i18n/date_time_format.dart:116: * String indicating a language code with
which the message is to be
Strictly I think language would be just the "en" part, and en-US would be a
locale code.

https://chromiumcodereview.appspot.com/10506006/diff/4001/lib/i18n/date_time_...
lib/i18n/date_time_format.dart:123: * written this way so that they can be
discoverable via autocomplete.
We should probably say where these come from and/or indicate what the characters
mean. While most are obvious, some are less so, e.g. L, E. Maybe even examples
would be good for the non-i18n literate.

https://chromiumcodereview.appspot.com/10506006/diff/4001/lib/i18n/date_time_...
lib/i18n/date_time_format.dart:125: static final String Hm = 'Hm';          //
HH:mm
So usage on these is, e.g.
   new DateTimeFormat(DateTimeFormat.Hms);
?
Are people going to want to type that instead of using the string literal? Is
the case significant on these? Seems like it probably is, but discoverability
would probably be better if all lowercase. But maybe autocomplete doesn't care.
Would named constructors for these be better? Or methods on Intl? e.g.
   new DateTimeFormat.Hms()
or 
   Intl.dateHms();

https://chromiumcodereview.appspot.com/10506006/diff/4001/lib/i18n/date_time_...
lib/i18n/date_time_format.dart:147: /** Date/Time format patterns. */
We should probably make this mechanism more consistent with the skeletons.

[Emily Fortuna, 2012-06-04 22:25:57]

https://chromiumcodereview.appspot.com/10506006/diff/4001/lib/i18n/date_time_...
File lib/i18n/date_time_format.dart (right):

https://chromiumcodereview.appspot.com/10506006/diff/4001/lib/i18n/date_time_...
lib/i18n/date_time_format.dart:6: * DateTimeFormat is for formatting and parsing
dates in a locale-sensitive
On 2012/06/04 19:58:37, Alan Knight wrote:
> I'd called it DateFormat because the objects it operates on are Dates, and we
> don't have either Time or DateTime objects. And it's shorter.

You're right. I'll fix it right now.

https://chromiumcodereview.appspot.com/10506006/diff/4001/lib/i18n/date_time_...
lib/i18n/date_time_format.dart:116: * String indicating a language code with
which the message is to be
On 2012/06/04 19:58:37, Alan Knight wrote:
> Strictly I think language would be just the "en" part, and en-US would be a
> locale code.

Done.

https://chromiumcodereview.appspot.com/10506006/diff/4001/lib/i18n/date_time_...
lib/i18n/date_time_format.dart:123: * written this way so that they can be
discoverable via autocomplete.
On 2012/06/04 19:58:37, Alan Knight wrote:
> We should probably say where these come from and/or indicate what the
characters
> mean. While most are obvious, some are less so, e.g. L, E. Maybe even examples
> would be good for the non-i18n literate.

Done.

https://chromiumcodereview.appspot.com/10506006/diff/4001/lib/i18n/date_time_...
lib/i18n/date_time_format.dart:125: static final String Hm = 'Hm';          //
HH:mm
On 2012/06/04 19:58:37, Alan Knight wrote:
> So usage on these is, e.g.
>    new DateTimeFormat(DateTimeFormat.Hms);
> ?
> Are people going to want to type that instead of using the string literal? Is
> the case significant on these? Seems like it probably is, but discoverability
> would probably be better if all lowercase. But maybe autocomplete doesn't
care.
> Would named constructors for these be better? Or methods on Intl? e.g.
>    new DateTimeFormat.Hms()
> or 
>    Intl.dateHms();

Realistically, no, people are not going to want to type that. They're provided
more to be discovered than for extensive use... see page 4 on my User Guide --
they can also be called as intl.date.Hms. I can provide named constructors for
these (in addition??) if that would be better (seems like it would).

https://chromiumcodereview.appspot.com/10506006/diff/4001/lib/i18n/date_time_...
lib/i18n/date_time_format.dart:147: /** Date/Time format patterns. */
On 2012/06/04 19:58:37, Alan Knight wrote:
> We should probably make this mechanism more consistent with the skeletons.

Fixing...