RE: [boost] Boost.Format syntax

From: Brey, Edward D (EdwardDBrey_at_[hidden])
Date: 2002-02-18 09:44:08

> From: James Kanze [mailto:kanze_at_[hidden]]
> 
> By your reasoning, one could argue that we could use [] as a power
> operator.  After all, you apply it to something to get something else:
> 
> |>  To understand any given application, consider:
> 
> |>  format("from 123 to [2]") [y]
> 
> |>  as choosing from this set of projections, as indexed by y:
> 
> |>  0: "from 123 to 0"
> |>  1: "from 123 to 1"
> |>  2: "from 123 to 2"
> 
> |>  and so on.
> 
> I find that you're stretching it some.  As I say, the same argument
> would apply to defining double::operator[]( double ) as a power
> function.

The difference between double and format is the same as between double and
map.  With map, the left operand by its nature allows for a narrow set of
operations that would make sense for any given operation.  For operator[],
only projection to the referent object makes sense.  The nature of the
format object provides a similar constraint.  Double is quite different.
You can do all sorts of things with a double given an operator and another
operand: raise to a power, take the nth root, trig functions, etc.  That's
why operator[] is ambiguous for double, but it is clear for map and format.

(Nuances of the operation can still be ambiguous, of course.  E.g., does map
insert or throw if the key doesn't exist?  BTW, I think that your comments
about the small-scale pros of operator[] in map versus its large-scale woes
were well put.)

> |>  What else could one
> |>  expect from the application of operator[] to a format object?
> 
> I would expect an error from the compiler:-).  Seriously, I 
> don't know.
> What else would you expect of applying [] to a double, except a power
> function.  
> 
> I think most programmers would expect it to give them the nth 
> character
> of the formatted string.  But I'm just guessing about this.

Interesting.  I never looked at it this way.  I would suspect that there
would be very few cases where someone would get confused about the meaning
in this way.  However, if I'm wrong, it would be a good argument against
operator[].

> |>  A desirable feature it to use similar syntax for both the format
> |>  specifier and argument delimiting.  So I'm not so sure that it is
> |>  practical to deal with them completely separately.
> 
> Why is that a desirable feature?  What does it buy us?

Just a bit of visual uniformity.  It helps the mind frame the context string
and the replacement values as a single logical thought.  On the scale of
desirable features, I'd say it ranks pretty low, for example way below the
desirability of passing the replacement values as formal arguments.