Re: [boost] Boost.Format syntax

From: Darin Adler (darin_at_[hidden])
Date: 2002-01-28 11:23:22

On 1/28/02 8:07 AM, "Brey, Edward D" <EdwardDBrey_at_[hidden]> wrote:

> But trying to find a nice syntax that allows it just isn't easy.  For example,
> using the "%1$s" use mentioned above, what happens if the value substituted is
> a string that the context string will make plural.  Its not pretty:
> format("%1$s %2$ss") [3] ["banana"].

This is one aspect of the printf format syntax, yes. We're not finding a
syntax here, we're using an existing one. And most programmers would use the
format "%s %ss", not the more-complex straw man you present. It's just
translators who need to reorder the string who would use "%2$s %1$s".

But adding an "s" suffix doesn't make a word plural anyway in general, so
this doesn't come up in my translatable programs.

> What harm is there in completely separating the printf syntax into a
> different class?  Is there really any desire to use (pseudo-)printf syntax
> and a modern syntax within the same format object?

I think there's no harm in that. I have no desire to mix the two.

>> For what it's worth, where printf compatibility is not an issue in my
>> programs, I use a formatting system with a syntax like this:
>> 
>>     "There's no space left on the disk named <disk>."
> 
> You're in luck.  C++ has this!
> cout << "There's no space left on the disk named " << disk << ".";

Perhaps you misunderstand. The string above goes into a translation database
and is translated into each language my program works in. This was the
subject of the motivating discussion at the outset of the format library
debate. The stream example you list doesn't do that.

Did you forget, or were you just ignoring this for the sake of the joke?

>> I find that the named parameters are easier to understand for translators
>> than numbered ones would be. And I don't try to create a terse C++ syntax for
>> this. I find that a normal sequence of function calls is just fine.
> 
> This obviously goes down the path of personal preference.  However, I think
> that existing languages can shed some light.  Note how modern languages that
> provide named function parameters (e.g. Python), still allow positional
> parameters.  There must be some value to them.  Likewise, note the tuple
> library in Boost.  Wouldn't structs be good enough?  The parallel isn't
> 100%, but it does indicate that there is some value to positional references
> when dealing with a small number of arguments.

The situation with named function parameters and the tuple library are not
analogous. The translators are dealing with the strings alone, not looking
at the corresponding code.

To clarify, I don't think a formatting library is as important if it
duplicates the stream functionality with a different interface that is
neither more suitable for translation nor compatible with printf. I want a
formatting library suitable for translation. Others want one that is
compatible with printf, and I think that's a nice idea too.

    -- Darin