Re: [boost] Review Request: Introduction of boost::string namespace and string-conversion functions

Subject: Re: [boost] Review Request: Introduction of boost::string namespace and string-conversion functions
From: Vladimir Batov (batov_at_[hidden])
Date: 2009-02-13 17:13:07

> Your counterarguments are not without merit but too easily dismiss the 
> problem when choosing a different name could resolve them readily.

1. If I wrote only a paragraph instead of a 3-volumes' analysis, it does not 
imply it was dismissed "too easily".
2. I sited that from my experience of actually having aux::string (for about 
5years) it was not a problem once.
3. I indeed think that by cryptic aliasing Andrey brings the obfuscation 
problem onto himself. Still he is adamant to deploy this technique. In such 
a setting I  feel he should be dealing with the consequences rather than me.
4. I'd expect it to be quite obvious (from this discussion) that *nothing* 
is resolved easily if more than one person involved.

>> Bo Persson also expressed a concern siting it'll make it
>> ...
>> Therefore, unless something major comes up later we are settling on
>> "boost::string".
>
> That's rather dismissive of the complaints.

I am not sure what you expected of me. I considered the complains. I counted 
how many complained (2) vs. how many replied but did not raise/see it as an 
issue (~5 with me). I provided summary and the result and moved on. What 
should I have done instead?

> "text," "convert," and "conversion" seem at least as good as "string."

I am sure "text" will be as controversial. The other two are not good as the 
idea was to have a namespace for anything-string related and not just 
conversion. So, are you *actually* suggesting something else or just 
criticizing my "dismissive" style? Does your original "for boost::string" 
stand? :-)

>> The "to/from/is" set seems to sit well with the majority of people.
>
> I don't understand how you can claim that.

I counted the number of people complaining and *not* complaining about any 
particular name. Then I compared the numbers. Then, I went with the bigger 
number.

> ... the tally, excluding yourself,

And you are excluding myself because...?

> ... A number complained about "to" and "from."

Again, I counted the numbers. I went with the bigger one and moved on. What 
am I missing?

> It didn't strike me that there was a majority favoring anything yet.

Well, I am not sure how I can react to a nebulous "It didn't strike me". 
Should I recount? Do you have different numbers/names showing I cheated? Do 
you feel I rushed and should have waited longer?

>> The to_string/from_string was floated around as alternatives.
>> I feel that
>> the "_string" extension indeed serves a mildly useful purpose
>> when the
>> "string" namespace is obfuscated. Like
>
> Not just obfuscation, as you describe it, but also elimination by way of 
> using directives or using declarations.

Elimination *is* obfuscation. You strip me of my name and then complain that 
you find it hard to address me. Does it immediately become *my* problem?

>>         namespace boost::string obfuscated;
>>
>>         string str = obfuscated::from(i); // What the...?
>>         string str = obfuscated::to_string(i); // Somewhat better but
>> still...
>>
>> When used sensibly
>>
>>         string str = boost::string::from(i);
>> or
>>         namespace boost::string str;
>>         string str = str::from(i);
>>
>> the intention seems clear
>
> Your notion of "sensible" use is not how all will use such functionality.

It is *never* possible to please all.

> Consider what can be extremely common:
>
> void f()
> {
>   using boost::<something>::from;
>   ...
>   std::string s(from(i));
>   ...
>   s = from(j);
>   // etc.
> }
>
> "from" is not as meaningful.  That name almost requires retaining the 
> enclosing namespace or a namespace alias.

I find it hard arguing against examples like that. It is clearly a bad 
practice. The solution is *not* to deploy it. And the solution lies with the 
user. The expectation of messing something up and expecting someone else 
having to deal with it sounds infantile to me. If one sticks his fingers 
into an electrical socket and gets hurt, should we immediately replace it 
with a horse power? Then, that poor horse will be guilty of trampling 
somebody who jumped under its feet...

>> Can we agree on the following interface:
>>
>>         template<class T, class String>
>>         boost::string::value<T>
>>         boost::string::to(String const&, T const& =T()) throw();
>
> I'm not convinced.  Naming is still an issue, of course, but this 
> interface doesn't include the Boost.Parameters idea, for example.

In other words, the interface *you* are suggesting is ... Without it it is 
hard to apply any metrics to such a broad range of opinions. We won't be 
able to please everyone. I'll go with the majority regardless it the 
minority is convinced or not.

>> 6. Something-To-String Conversion Interface.
>>
>> That did not seem to generate much heat at all. I'll
>> summarize to make
>> sure we see it the same way:
>>
>>         template<class T>
>>         boost::string::value<std::string>
>>         boost::string::from(T const&) throw();
>
> Same answer.

I do not feel I can decisively act on your answer and need more information 
about what exactly you are proposing.

>> Does not throw. No default value (do we need one?). Returns
>
> If T is not restricted to built-ins, then there are many reasons why the 
> conversion would fail.  If the function is not to throw an exception, then 
> there would need to be a default.  (Imagine using this for input 
> validation, which can set the stream state to fail when the validation 
> fails.)

Yes, I think it makes sense.

         template<class T>
         boost::string::value<std::string>
         boost::string::from(T const&, std::string const& =std::string()) 
throw();

Looks right?

>> 8. Throw/No-Throw Behavior.
> ...
> Yes and no.  Both approaches should be supported from the start.  Getting 
> an exception makes calling code simpler, but code that expects failures or 
> that can't use or afford exceptions in some context would benefit from the 
> non-throwing interface.  Yes, others can add exceptions to the 
> non-throwing version, but it would be better to include that in the 
> library.
> The non-throwing version could be requested using overloading with 
> std::nothrow_t.

I'll have to think about it. I do not like the "std::nothrow_t"-based 
solution as my usage-pattern is largely non-throwing. So, I do not want 
typing std::nothrow_t all the time.

> ...
> The string-oriented focus may be the problem with the namespace and 
> function names.  Perhaps this functionality be merged with the 
> lexical_cast improvement ideas to create a general purpose type conversion 
> facility.  Instead of thinking about conversions to and from strings, 
> think of those conversions as special cases of a more general type-to-type 
> converter of which lexical_cast is a degenerate form.  That suggests 
> something like using "conversion" as the namespace name and replacing "to" 
> and "from" with "convert."

The "lexical_cast improvement" was the original suggestion. It did not fly 
with many people (including the author and the maintainer). So, the 
decision's been made to start fresh.

V.