Re: New compose and format API

[manphiz <manphiz gmail com>]

Daniel Elstner wrote:
> There is no restriction beyond what's imposed by the placeholder syntax,
> which only goes up to "%9".  I think nine arguments are more than enough
> for the purpose of generating user-visible message strings.
>
> [...]
>
> Both are type safe.  Variadic functions are definitely out of the
> question.  I don't have qualms with the operator%() syntax, but I'm not
> sure the minor syntax difference is worth the additional bloat required
> to implement it.  (It would be necessary to accumulate and concatenate
> the results of the operator at each step.)

Got it, and I agree with the original function-call syntax, which is 
more straightforward and can even be improved when variadic template 
comes into reality.

> Well, we aren't trying to replace boost or the STL.  The main concern is
> proper internationalization of GUI applications.  Using a multi-byte
> encoding such as UTF-8 as the internal encoding in an application was
> never anticipated in the design of the C++ STL.  The implementation of
> ustring::format() does some pretty crazy stuff to get everything right,
> such as passing everything through a wide-character stream and doing the
> necessary conversions from and to UTF-8.  A generic implementation would
> be an entirely different beast.  But as I said we aren't trying to
> replace boost, and nothing is stopping you from converting the result of
> ustring::format() to a different string type.
>
> [...]
>
> It's not just string types, it's also about locales and using UTF-8 as
> the single encoding for everything.  Trying to make this feature generic
> would defy the original goal of providing a straightforward way to get
> internationalization right in the context of gtkmm applications.  Right
> now there so many little gotchas involved that you have to be an expert
> in internationalization to get it right.
>
> Cheers,
> --Daniel

I got the point this time. Based on these principles of ustring::compose 
and ustring::format, current implementation has already done a great job.

And, based on the reply from Boost mailing list, boost::format thing 
might not be happening in the standard, which will have type-safe 
s{,n}printf stuff with variadic templates. So, ustring::compose is on 
its own now, which may be a good thing, since there's no standardization 
restriction any more, it can do whatever it wants to within C++ 
philosophy. So now I'm totally ok with it. Together with some possible 
revise from the discussions which might ensue, I believe 
ustring::compose will play an important role in gtkmm. I'll take a more 
close look at it. Thanks again for your effort :)