Possibility of standardized sprintf() in ES4?
I would be very interested in this. Have a look at our
implementation (not called sprintf, but has similar goals). Our
implementation has an additional goal of keeping an association
between the result string and the objects it represents. Being a
dynamic language, I think es4 should aspire to more than just C sprintf.
svn.openlaszlo.org/openlaszlo/trunk/WEB-INF/lps/lfc/compiler LzFormatter.lzs
Our source is licensed under CPL.
...
Is there any other interest in adding a native sprintf() (probably as String.sprintf()) to the ES4 specs?
I'm interested in string formating, but surely not sprintf I don't find it intuitive at all
I prefer something closer to String.format from .NET but more dynamic and being able to use sort of tokens like the ones you can use with E4X (<node>{token}</node>)
see here for an implementation maashaack.googlecode.com/svn/trunk/ES4a/src/system/Strings.as ( public static function format( format:String, ...args ):String )
On 15/10/2007, ekameleon <ekameleon at gmail.com> wrote:
Hello :)
Yes i prefere too the Strings.format implementation :) For me it's an important feature and can be insert in the core String methods :)
EKA+ :)
2007/10/15, zwetan <zwetan at gmail.com>:
Hi,
...
Is there any other interest in adding a native sprintf() (probably as String.sprintf()) to the ES4 specs?
I'm interested in string formating, but surely not sprintf I don't find it intuitive at all
I prefer something closer to String.format from .NET but more dynamic and being able to use sort of tokens like the ones you can use with E4X (<node>{token}</node>)
see here for an implementation maashaack.googlecode.com/svn/trunk/ES4a/src/system/Strings.as ( public static function format( format:String, ...args ):String )
cheers, zwetan
Es4-discuss mailing list Es4-discuss at mozilla.org, mail.mozilla.org/listinfo/es4-discuss
Es4-discuss mailing list Es4-discuss at mozilla.org, mail.mozilla.org/listinfo/es4-discuss
Sure. From what I can see of the Microsoft documentation a standardized String.format() function would meet the need for a standardized way of formatting a string just as well as a method based on C/Perl/PHP/Ruby sprintf() and Python's native string formatting, where named parameters are used instead of positional parameters.
Assuming there are no intellectual property concerns with adopting Microsoft's specification for this method, it would satisfy my use case for a string formatting method that accepts explicit positional or named parameters in support of internationalized text. I would simply be delighted if ES4 saved me and others from having to roll our own string formatter classes!
I would be all for .NET's String.Format() style of formatting. Adobe Flex provides a similar method in StringUtil.substitute() which provides ordered substitution using the same {0} and {1} style tokens, but doesn't have any formatting.
Sam
We're Hiring! Seeking a passionate developer to join our team building Flex based products. Position is in the Washington D.C. metro area. If interested contact careers at blinemedical.com
[ snip ]
Sure. From what I can see of the Microsoft documentation a standardized String.format() function would meet the need for a standardized way of formatting a string just as well as a method based on C/Perl/PHP/Ruby sprintf() and Python's native string formatting, where named parameters are used instead of positional parameters.
Python allows both, and I prefer that style.
Assuming there are no intellectual property concerns with adopting Microsoft's specification for this method, it would satisfy my use case for a string formatting method that accepts explicit positional or named parameters in support of internationalized text. I would simply be delighted if ES4 saved me and others from having to roll our own string formatter classes!
Eh, just go w/ Python's. It's more flexible, "feels" more like printf if/when you need it to, and can be used in the .NET-ish way.
On 16/10/2007, Alex Russell <alex at dojotoolkit.org> wrote:
[ snip ]
Sure. From what I can see of the Microsoft documentation a standardized String.format() function would meet the need for a standardized way of formatting a string just as well as a method based on C/Perl/PHP/Ruby sprintf() and Python's native string formatting, where named parameters are used instead of positional parameters.
Python allows both, and I prefer that style.
Assuming there are no intellectual property concerns with adopting Microsoft's specification for this method, it would satisfy my use case for a string formatting method that accepts explicit positional or named parameters in support of internationalized text. I would simply be delighted if ES4 saved me and others from having to roll our own string formatter classes!
Eh, just go w/ Python's. It's more flexible, "feels" more like printf if/when you need it to, and can be used in the .NET-ish way.
Just following up on the discussion - since I've seen an announcement that the spec for ES4 is now closed, does this mean that a proposal for an addition of a standardized sprintf / format addition to the String object is off the table until ES5? Or have the Ecma members of the group decided that there is no actual requirement for this functionality?
Beyond raising this issue on the mailing list and finding some support in principle for the proposal, if not for the actual form of the proposal, I'm not sure what the next step is supposed to be. It does seem like a major functionality gap in the language, to me, but I'm only one small voice.
On Oct 27, 2007, at 11:06 AM, Dan Scott wrote:
Just following up on the discussion - since I've seen an
announcement that the spec for ES4 is now closed, does this mean
that a proposal for an addition of a standardized sprintf / format
addition to the String object is off the table until ES5? Or have
the Ecma members of the group decided that there is no actual
requirement for this functionality?
See doku.php?
id=discussion:string_formatting and also
doku.php?id=meetings:minutes_feb_24_2006&s=string+formatting, which
contains:
String formatting choices:
* Leave out, defer to the emergent standard library ecology?
Then lose type system tie-in opportunites.
* .NET vs. MSCOM vs. Java vs. others leaves no single obvious
choice of what to imitate.
* OCaml, other precedents? Roll-our-own function-combinatorial
typed formatting? Too inconvenient.
* Ed points out that strings imply localization, more worms.
These considerations suggested to us that we defer this to the
library ecosystem. But we could have missed an opportunity here.
Beyond raising this issue on the mailing list and finding some
support in principle for the proposal, if not for the actual form
of the proposal, I'm not sure what the next step is supposed to be.
It does seem like a major functionality gap in the language, to me,
but I'm only one small voice.
In your view, is it a gap in the standard library, a gap to fill by
competing libraries before anything is standardized, or truly a gap
in the core language? For there to be a gap in the core language, it
seems to me the proposal must involve static type checking of actual
arguments against format specifiers. Otherwise, as Lars noted in the
discussion page, even ES3 has enough reflection to build a
dynamically type-safe formatter as library code. Successful Ajax
libraries have built such things.
On 27/10/2007, Brendan Eich <brendan at mozilla.org> wrote:
On Oct 27, 2007, at 11:06 AM, Dan Scott wrote:
Just following up on the discussion - since I've seen an announcement that the spec for ES4 is now closed, does this mean that a proposal for an addition of a standardized sprintf / format addition to the String object is off the table until ES5? Or have the Ecma members of the group decided that there is no actual requirement for this functionality?
See doku.php? id=discussion:string_formatting and also doku.php?id=meetings:minutes_feb_24_2006&s=string+formatting, which contains:
String formatting choices:
* Leave out, defer to the emergent standard library ecology?Then lose type system tie-in opportunites. * .NET vs. MSCOM vs. Java vs. others leaves no single obvious choice of what to imitate. * OCaml, other precedents? Roll-our-own function-combinatorial typed formatting? Too inconvenient. * Ed points out that strings imply localization, more worms.
These considerations suggested to us that we defer this to the library ecosystem. But we could have missed an opportunity here.
Ah, fabulous - it seems that although the term "sprintf" appears in the wiki, it's highlighted and therefore doesn't turn up in a search for the term. And I was too dumb to search for "string format" -- thanks for letting me know that the issue had been raised in the past and that there had been some discussion about it.
Beyond raising this issue on the mailing list and finding some
support in principle for the proposal, if not for the actual form of the proposal, I'm not sure what the next step is supposed to be. It does seem like a major functionality gap in the language, to me, but I'm only one small voice.
In your view, is it a gap in the standard library, a gap to fill by competing libraries before anything is standardized, or truly a gap in the core language? For there to be a gap in the core language, it seems to me the proposal must involve static type checking of actual arguments against format specifiers. Otherwise, as Lars noted in the discussion page, even ES3 has enough reflection to build a dynamically type-safe formatter as library code. Successful Ajax libraries have built such things.
I n my view, it's simply a gap in the standard library (and I apologize if this was not the correct forum to raise concerns about the standard library vs. the core language spec). As I noted at the outset, there are a wide variety of sprintf() (and probably String.format()) implementations already out in the wild under various licenses and with varying sophistication. I believe that adding such a method to the standard library would help simplify the current situation and increase the ease of reusing code between projects.
Thanks for taking the time to respond, Brendan - I really appreciate it, as well as the rest of your efforts to bring ES4 to fruition.
On Oct 28, 2007, at 4:39 PM, Dan Scott wrote:
Ah, fabulous - it seems that although the term "sprintf" appears in
the wiki, it's highlighted and therefore doesn't turn up in a
search for the term. And I was too dumb to search for "string
format" -- thanks for letting me know that the issue had been
raised in the past and that there had been some discussion about it.
I'm not sure the wiki search indexing is working correctly atm. We'll
look into it.
In my view, it's simply a gap in the standard library (and I
apologize if this was not the correct forum to raise concerns about
the standard library vs. the core language spec).
No worries, for better or worse, ECMA-262 specifies both core
language and standard library.
As I noted at the outset, there are a wide variety of sprintf()
(and probably String.format()) implementations already out in the
wild under various licenses and with varying sophistication. I
believe that adding such a method to the standard library would
help simplify the current situation and increase the ease of
reusing code between projects.
But which one? Whose ox gets gored? What about l10n? Etc.
You can tell we didn't have the bandwidth to take this on, and with
so many JS libs purveying variations on a theme, we chose the virtue
of not committing the standard to one particular string formatting
library. But no matter the timing, having a concrete proposal would
help. Can you link to the Microsoft String.format API doc?
Hello:
I've been working on a project requiring i18n support in ES (open-ils.org), and it's become clear that a standard sprintf() implementation in ES would have been very useful. There are currently some open-source sprintf() implementations written in ES, but all of the ones I've looked at so far seem to either have unusual licenses or incomplete implementations (positional specifier support is absolutely necessary for i18n, for example.) hexmen.com/blog/2007/03/printf-sprintf is probably the closest thing I've found to a solution yet.
For something as basic as string formatting, it would be great to be able to count on a core implementation of sprintf() (or something equivalent) in a future version of ES. Jon Udell made a comment to the effect that string formatting was a part of the TG1 wiki at weblogs.mozillazine.org/roadmap/archives/2006/02/js_and_python_news.html, but I've been unable to find that section in the wiki (unless that is limited strictly to String.replace()).
Is there any other interest in adding a native sprintf() (probably as String.sprintf()) to the ES4 specs?