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: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2009-02-17 13:34:21

Vladimir Batov wrote:
> Rob Stewart wrote:
>
> > 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".

You snipped the text I quoted, but I was referring to the wording as much as to the conclusion.  You've noted elsewhere that English is not your native language.  Your name suggests that possibility, of course, but we have no way to know if we don't know you.  I read what you wrote and cannot infer what you meant.

> 2. I sited that from my experience of actually having
> aux::string (for about
> 5years) it was not a problem once.

Your citation is of some value, but perhaps less than you think as you and those with whom you work comprise a small audience with certain usage patterns and don't necessarily reflect the wider audience.

> 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.

I understand your point, yet you should consider alternatives that fit your notions but don't cause any more difficulty than necessary to others.  The point, after all, is to maximize the audience of what you create, isn't it?

> 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?

As has been noted, you arrived at your conclusion very soon after your initial post.  Some folks that might be interested might have been on vacation, ill, busy, etc.  Some might have simply lurked noting that another had voiced their concern.  You had insufficient information and hadn't allowed enough time for consensus, so the conclusion you reached, and the language used -- there's that English issue again, of course -- lead to my comment.

Just saying things like, "therefore, it seems as if most like,..." would describe your conclusion without peremptorily ending discussion.

> > "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? :-)

After seeing other concerns, and considering other issues, I became less enamored of boost::string.  Conversion is not just limited to string to/from other things, so I'm inclined to think that it should be managed apart from an "anything string" namespace.  It may be that boost::conversion::convert(...) is implemented in terms of boost::string::to/from, thus satisfying both.  (I'm not advocating any names as yet, just using those as examples.)

> >> 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.

This is, again, a problem of being too early.  It is also a problem of counting all votes equally when some arguments are technical, others forward looking, and still others merely preference.  Some concerns may merit more weight than others.

> > ... the tally, excluding yourself,
>
> And you are excluding myself because...?

It was your idea, so you're biased.  If you're trying to evaluate the merit of your idea, it seems misleading to count your own vote in its favor.

> > ... 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?

As before.

> > 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?

I wasn't accusing you of cheating, but operating upon too few samples to arrive at a statistically significant conclusion.

> >> 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?

I disagree that it is obfuscation.  In one context, referring to me as "Dad" is perfectly clear.  In another, "Rob" is appropriate.  In yet another, more of my name is needed.  I've never had the problem you suggest with names from any other namespace.  There can be a question of which type or function is meant when there is more than one namespace providing that name, but when there is ambiguity the compiler requires scope resolution anyway.  Otherwise, I've found names to work well without namespace scope.  Yours are the first I've encountered to the contrary suggesting they could be improved.

> > Your notion of "sensible" use is not how all will use such
> functionality.
>
> It is *never* possible to please all.

I wasn't suggesting that you should try to do so.  However, using directives *are* common, even if not in your code.

> > 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.

Wow!  I thought we were being reasonable until this point.  Apparently, I'm a horrible developer and clearly do bad things.  In case my sarcasm isn't obvious, I do not accept your criticism of what I showed in the example.  It *is not* bad practice.

> >> 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 ...

I don't yet understand the entire scope, so I can hardly suggest alternatives.

> 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.

The right design is right whether the majority agrees, at least at first, 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.

I cannot say more without a better understanding of the short and long term goals.  As you have submitted your request for a formal review already, I wonder why I'm taking the time to respond to any of this.

> >> 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?

Maybe

> > 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.

Yes, but you have an opportunity to create a new, general purpose conversion framework that does more than just conversions to and from string, with the latter merely a special case.  Instead of retrenching from lexical_cast to nothing but conversions to/from strings, I'm suggesting a wider scope.

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer, Core Software      using std::disclaimer;
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.