-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Am 09.03.2011 19:48, schrieb P T Withington:
Disagree. Since ECMAScript knows the type of the arguments, it does _not_
need the format specifier to tell it the type (as C does).
Perhaps not for the data type - but for the representation of
On Wed, 09 Mar 2011 01:21:09 +0100, Shanjian Li shanj...@google.com
wrote:
http://wiki.ecmascript.org/doku.php?id=strawman:string_format_take_two
Please kindly review the proposal and let me know your feedback.
Just some nitpciking:
It doesn't specify how to print objects, except for %s,
Right. I didn't give much thought about possible XSS and other injection
vulnerabilities. I am open to idea about how this thing can be misused and
if anything can be done about it.
The purpose of this proposal is to provide a way for developer to
conveniently construct a string, and for
Comment inline.
On Wed, Mar 9, 2011 at 12:37 AM, Lasse Reichstein
reichsteinatw...@gmail.com wrote:
On Wed, 09 Mar 2011 01:21:09 +0100, Shanjian Li shanj...@google.com
wrote:
http://wiki.ecmascript.org/doku.php?id=strawman:string_format_take_two
Please kindly review the proposal and let
On 2011-03-09, at 13:20, Shanjian Li 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
It is ok for a give format specifier to apply to multiple type of object. In
your example, 'x' is applied to an array of numbers. But the language
interpreter should not do a hidden conversion to make it applicable. For
example, {0:x}.(48) should throw an exception instead of trying to do a
Implicit function calls within string formatting operations seem like the sort
of concept that is likely to lead to security problems on websites and the like.
This isn't a matter of can the engine do this safely it's a question of
whether the author expects arbitrary code execution to occur
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
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 wrote:
It
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
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 2:46 PM
To: 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
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
...@mozilla.org] On Behalf Of Gillam, Richard
Sent: Wednesday, March 09, 2011 2:46 PM
To: 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
]
On Behalf Of Gillam, Richard
Sent: Wednesday, March 09, 2011 2:46 PM
To: es-discuss@mozilla.orgmailto: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
.
- Shawn
http://blogs.msdn.com/shawnste
-Original Message-
From: 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
Subject: Re: A proposal to add
-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
Subject: Re: A proposal to add String.prototype.format
It seems worth mentioning that this functionality sounds an awful lot
.
- Shawn
http://blogs.msdn.com/shawnste
-Original Message-
From: 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
Subject: Re: A proposal to add
EcmaScript lacks a method to format strings in a flexible and controllable
manner. Most EcmaScript strings are constructed by concatenating a series of
substrings. Such practice really hurts code readability. Especially for
localization, it is almost impossible to translate the string when it is
[+msamuel]
I don't understand. I see that this proposal references quasis, but I don't
see how it subsumes the safety quasis provide against quoting confusions,
e.g., that lead to XSS and other injection vulnerabilities. What am I
missing?
On Wed, Mar 9, 2011 at 12:21 AM, Shanjian Li
20 matches
Mail list logo
