A proposal to add String.prototype.format
Shawn Steele
Shawn.Steele at microsoft.com
Wed Mar 9 14:53:32 PST 2011
I would postpone any formatting stuff until the i18n stuff was better understood.
- Shawn
http://blogs.msdn.com/shawnste
-----Original Message-----
From: es-discuss-bounces at mozilla.org [mailto:es-discuss-bounces at mozilla.org] On Behalf Of Gillam, Richard
Sent: Wednesday, March 09, 2011 2:46 PM
To: es-discuss at 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 <shanjian at 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 <rnystrom at 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, 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 - reichsteinatwork at gmail.com
>>>>
>>>>
>>>> _______________________________________________
>>>> es-discuss mailing list
>>>> es-discuss at mozilla.org
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>>
>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
>
>
> --
> Adam Shannon
> UNI Freshman
> Web Developer
> ashannon.us
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss at mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
More information about the es-discuss
mailing list