I think we should keep deep object names, JSON data structures are
often nested a little bit and it's nice to be able to work with them
as-is without creating a new object just to flatten it out.
As far as nested replacements go, I think we can ditch that safely.
I've never really wanted to use that.
Otherwise the proposal looks good! :)
On Wed, Sep 10, 2008 at 12:53 PM, Per Cederberg <[EMAIL PROTECTED]> wrote:
>
> Thank you everyone for the interesting comments. I had a look at PEP
> 3101 (Python 3), the (new) Java 1.5 Formatter API and a popular
> sprintf implementation for JavaScript. And in the end, it seems hard
> to strike a good balance between readable syntax, power features and
> localization. Actually, I think they all fail at one or the other.
>
> In PEP 3101 I couldn't find any mention of the thousand separator (at
> first, but now I just realized that ":n" should be used). The Java
> Formatter API took the already ugly sprintf-syntax to new heights of
> unreadability. And the standard sprintf variants are problematic for
> localized format strings where the order of the parameters might
> change.
>
> So, I'm thinking about using a simplified version of PEP 3101 with a
> few add-ons to enable most of what is possible with the current
> numberFormatter function.
>
> I'm thinking that the API should look something like:
>
> // Create a formatter function for specified pattern & locale
> MochiKit.Format.formatter(pattern/*, locale="default" */)
> ==> <function object>
>
> // Short-cut that immediately applies the formatter on the specified args
> MochiKit.Format.format(pattern/*, ... */)
> ==> <formatted string>
>
> Perhaps a few examples would best explain the formatting patterns:
>
> // Simple positional replacements
> format("A {1} string with {0} arguments.", "numeric", "format")
> ==> "A format string with numeric arguments."
>
> // Or we use object properties
> format("{name} == {value}", { value: 2, name: "a" })
> ==> "a == 2"
>
> // As usual, escaping is performed by double chars
> format("{{}}")
> ==> "{}"
>
> // Differing from Python, the default is a toString()
> format("{0}", 1/3)
> ==> "0.3333333333333333"
>
> // Naturally, null is supported as "null"
> format("{0}", null)
> ==> "null"
>
> // We can force a decimal format
> format("{0:d}", 1.5)
> ==> "1"
>
> // And a fixed number of characters
> format("{0:4d}", -4)
> ==> " -4"
>
> // We can force the field to be left-aligned
> format("{0:<4d}", 4)
> ==> "4 "
>
> // Or add zero padding
> format("{0:04d}", 4)
> ==> "0004"
>
> // Using the repr() output
> format("{0:r}", "foo")
> ==> "\"foo\""
>
> // I suggest we skip nested replacements due to complexity
> format("{0:{1}}", 4, 3)
> ==> error, but in Python it would be " 4"
>
> // I'd also reject deep object names as it is just not useful enough
> format("{sub.name}", { sub: { name: "Alice" } })
> ==> error, but in Python it would be "Alice"
>
> So the format for the replacement string is:
> "{" key ":" fmt "}"
>
> The format string has the following (Python) format:
> [flags][width][.precision][type]
>
> Flags:
> '>' - Forces the field to be right-aligned (default).
> '<' - Forces the field to be left-aligned.
> '+' - Sign should be used for both positive and negative numbers.
> '-' - Sign should be used only for negative numbers (default).
> ' ' - Leading space should be used on positive numbers.
> '0' - Numbers will be zero-padded to the specified width.
> ',' - The result will include locale-specific grouping (thousand separators).
>
> Width specifies the minimum field width. The precision indicates how
> many digits should be displayed after the decimal point in a floating
> point conversion. For non-numeric types the field indicates the
> maximum field size.
>
> Suggested formatting types:
> s - Output from toString(), this is the default
> r - Output from MochiKit.Base.repr()
> b - Binary. Outputs the number in base 2.
> c - Character.
> d - Decimal Integer. Outputs the number in base 10.
> o - Octal format. Outputs the number in base 8.
> x - Hex format. Outputs the number in base 16, using lower-case letters.
> X - Hex format. Outputs the number in base 16, using upper-case letters.
> f - Fixed point number.
> % - Percent conversion for a fixed point number (and adds a '%' char
> at the end).
> ... perhaps some format for exponents (but it would be hard to implement)
> ... and some nice time formatting stuff
>
> I think the above would support most of the common use cases for
> formatting, while leaving it fairly simple to implement in plain
> JavaScript. If more advanced formatting is required, one can always
> write specialized functions that re-use these components accordingly.
>
> Opinions? Think I'll start on this next week otherwise.
>
> Cheers,
>
> /Per
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"MochiKit" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---
