If we're going to ultimately have two APIs that do the same thing-- a generic
one and an internationalized one-- can we at least avoid having them have
gratuitously different pattern formats and styles of operation?
--Rich Gillam
Lab126
On Mar 9, 2011, at 3:01 PM, Nebojša Ćirić wrote:
This proposal intentionally avoids i18n issues and focuses on general
formatting. One can still use i18n features from our API like so:
var locale = new LocaleInfo();
var df = locale.dateTimeFormat();
"I got married on {0}".format(df.("12/03/2001"));
MessageFormat was focusing on plurals and gender, and we couldn't reach
consensus on actual message format and scope, so we postponed it. Also, we aim
to avoid adding i18n API objects into core language at this moment.
09. март 2011. 14.53, Shawn Steele
<shawn.ste...@microsoft.com<mailto:shawn.ste...@microsoft.com>> је написао/ла:
I would postpone any formatting stuff until the i18n stuff was better
understood.
- Shawn
http://blogs.msdn.com/shawnste
-----Original Message-----
From: es-discuss-boun...@mozilla.org<mailto:es-discuss-boun...@mozilla.org>
[mailto:es-discuss-boun...@mozilla.org<mailto:es-discuss-boun...@mozilla.org>]
On Behalf Of Gillam, Richard
Sent: Wednesday, March 09, 2011 2:46 PM
To: es-discuss@mozilla.org<mailto:es-discuss@mozilla.org>
Subject: Re: A proposal to add String.prototype.format
It seems worth mentioning that this functionality sounds an awful lot like what
MessageFormat does, and MessageFormat was in the i18n strawman (and I have it
in my own i18n implementation). It doesn't seem like we need two different
"formatted string" APIs.
--Rich Gillam
Lab126
On Mar 9, 2011, at 2:36 PM, Adam Shannon wrote:
> I rather like the idea of having this syntax for string formatting:
>
> "name: {name:first} {name.last}".format(name)
>
> It allows for more complex operations
>
> "name: {person.firstName} \nstart:
> {myEvent.startTime}".format(myEvent, person)
>
> Also, it doesn't require mundane fixes later on and keeps things
> simple for the developer. (No needed knowledge or maintenance of
> things based on position.)
>
> On Wed, Mar 9, 2011 at 15:36, Shanjian Li
> <shanj...@google.com<mailto:shanj...@google.com>> wrote:
>> I like this idea. I thought a lot about how to support those locale
>> specific stuff like plural and gender. Your suggestion provide an
>> elegant way to transfer the responsibility to a more appropriate party.
>>
>> shanjian
>>
>> On Wed, Mar 9, 2011 at 1:18 PM, Bob Nystrom
>> <rnyst...@google.com<mailto:rnyst...@google.com>> wrote:
>>>>>
>>>>> It doesn't specify how to print objects, except for %s, which says
>>>>> that if the argument is not a string, convert it to string using
>>>>> .toString().
>>>>
>>>> If the format specifier does not apply to the argument given, it
>>>> should raise exceptions. Except string conversion, no other
>>>> conversion will be done.
>>>
>>> I like your first six points, but the formatting string stuff feels
>>> odd to
>>> me: neither dynamic nor object-oriented. C needs format specifiers
>>> because it doesn't otherwise know now to interpret the bits you
>>> give. ES doesn't have that problem.
>>> At the same time, baking a rigid set of formatting instructions into
>>> string.format() feels like a poor separation of concerns.
>>> string.format()'s just is to compose a string out of smaller pieces.
>>> Why should it need to know anything about numbers or dates?
>>> Could we just say that this:
>>> "hi, {0:blah}.".format(someObj); Is (conceptually) desugared to:
>>> ("hi, " + someObj.toFormat("blah") + ".") So anything after the
>>> ":" in an argument (the format string) gets passed to the object
>>> itself by way of a call to toFormat() (or some other method
>>> name) on it. Then each object can decide what format strings are
>>> appropriate for it.
>>> This keeps the responsibilities separate: string.format() does
>>> composition, and the composed object own their own formatting. It's
>>> also
>>> extensible: you can define your own formatting capabilities for your
>>> types and use them with string.format() by defining toFormat(). (By
>>> default, I would assume that Object.prototype.toFormat() just calls
>>> toString()).
>>> This, I think, helps with locale issues too. Types like Date that
>>> care about locale will be able to handle it themselves in their call
>>> to
>>> toFormat() without string.format() needing to deal with it.
>>> - bob
>>>
>>>>
>>>>
>>>>>
>>>>> The string conversion should probably use the internal ToString
>>>>> function instead (which works for null and undefined too).
>>>>
>>>> Agree.
>>>>
>>>>>
>>>>> For formats expecting numbers, it should convert the argument to a
>>>>> number using ToNumber.
>>>>
>>>> Probably not. As string is the thing being constructed, it make
>>>> sense to offer "hidden" string conversion. In my experience using
>>>> this feature in Python, it is within expectation and offer some
>>>> convenience. Any further "hidden" conversion should really be avoided.
>>>>
>>>>>
>>>>> Rounding is specified as "math.round(n - 0.5)" (capital M in Math?).
>>>>
>>>> Right, thanks.
>>>>
>>>>>
>>>>> This leaves it open whether overwriting Math.round should change
>>>>> the behavior of format. It probably shouldn't (i.e., again it
>>>>> would be better to specify in terms of internal,
>>>>> non-use-modifiable functions).
>>>>
>>>> Agree.
>>>>
>>>>>
>>>>> The rounding is equivalent to Math.floor(n) (aka round towards
>>>>> -Infinity), if I'm not mistaken, so why not just use that?
>>>>
>>>> In this example, 8 / (3 - 8 / 3) , the display will be 23.99999999999999.
>>>> So the internal representation could be a little bit more or a
>>>> little bit less than the theoretical value due to float precision.
>>>> Math.round might generate less surprise results than Math.floor.
>>>> Of cause, the internal implementation shouldn't rely on either of these
>>>> two.
>>>>
>>>>>
>>>>> (Personally I would prefer truncation (round towards zero), if
>>>>> conversion to integer is necessary).
>>>>>
>>>>> Why can octal, binary and hexidecimal forms only be used on integers?
>>>>> Number.prototype.toString with
>>>>> an argument works on fractions too (try Math.PI.toString(13) for
>>>>> laughs :).
>>>>
>>>>
>>>>>
>>>>> Why only fixed bases (2,8,10,16)? How about adding an optional
>>>>> base parameter to number display (with x, d, o, b as shorthands
>>>>> for the more standard bases)? Again, Number.prototype.toString
>>>>> means that it's already in the language. (I know that step 7 says
>>>>> copy the format of other languages, but that seems shortsighted
>>>>> since ECMAScript is not those languages, and only copying
>>>>> functionality from C verbatim seems like tying your shoelaces
>>>>> together before the race).
>>>>>
>>>> The question for both questions is how useful is that. If it is
>>>> only needed in one or few rare occasions, it is probably not a good
>>>> idea to complicate the language.
>>>>
>>>>>
>>>>> "Placeholder used in format specifier part can not have format
>>>>> specifier. This prevent the replacement from embedding more than
>>>>> one level."
>>>>> Should that be "... can not have a placeholder."?
>>>>
>>>> No. The former prevent any format specifier (including embedded
>>>> placeholder). Refer to the Python specification, it does make sense.
>>>>
>>>>>
>>>>> If the placeholder value is not a string, it should be converted
>>>>> to a string.
>>>>> If it is not a valid format, what happens then?
>>>>
>>>> Raise exception?
>>>>
>>>>>
>>>>> Is the following valid:
>>>>> "{x} and {1[y]}".format({x:42},{y:37}) I.e., can object property
>>>>> shorthands ({x} instead of {0[x]}) be used if there are more than
>>>>> one argument?
>>>>
>>>> Good points. Possible choices:
>>>> 1. {x} always refer to the first object given.
>>>> 2. {x} only works when there is one and only one object argument.
>>>> 3. {x} will be replaced by the first object that has property x,
>>>> ie. the following should work too.
>>>> "{x}, {z} and {1[y]}".format({x:42}, {z:43, y:37})
>>>>
>>>> I prefer 1.
>>>>
>>>>>
>>>>> And some arbitrary ideas for extension:
>>>>>
>>>>> How about a boolean test that checks for falsy-ness of the
>>>>> argument and acts as one of two other formats or literals?
>>>>> E.g.
>>>>> "{0:s} drew {1:?his|her} gun.".format(person.name<http://person.name/>,
>>>>> person.isMale)
>>>>> "Please press return{0:?.|{1}}".format(notCritical, " and run!")
>>>>
>>>> Interesting. In example 1, the issue is literal get into the
>>>> placeholder, that could make things messy.
>>>>
>>>>>
>>>>> Or allow computed indices?
>>>>> "{0[{1}][he]} drew {0[{1}][his]}
>>>>> gun.".format({male:{he:"He",his:"his"},
>>>>> female:{he:"She",his:"her"}}, "female");
>>>>
>>>> Allow embedded placeholder inside the field part (not the format
>>>> specifier part) of a placeholder is something that I will be very
>>>> cautious about.
>>>> shanjian
>>>>
>>>>>
>>>>> /L
>>>>> --
>>>>> Lasse Reichstein -
>>>>> reichsteinatw...@gmail.com<mailto:reichsteinatw...@gmail.com>
>>>>
>>>>
>>>> _______________________________________________
>>>> es-discuss mailing list
>>>> es-discuss@mozilla.org<mailto:es-discuss@mozilla.org>
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>>
>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss@mozilla.org<mailto:es-discuss@mozilla.org>
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
>
>
> --
> Adam Shannon
> UNI Freshman
> Web Developer
> ashannon.us<http://ashannon.us/>
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org<mailto:es-discuss@mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org<mailto:es-discuss@mozilla.org>
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org<mailto:es-discuss@mozilla.org>
https://mail.mozilla.org/listinfo/es-discuss
--
Nebojša Ćirić
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
