Re: [boost] Formal Review Request: Boost.String.Convert

Subject: Re: [boost] Formal Review Request: Boost.String.Convert
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2009-02-18 12:46:10

On Wed, Feb 18, 2009 at 5:52 AM, Stewart, Robert <Robert.Stewart_at_[hidden]> wrote:
> On Tuesday, February 17, 2009 5:43 PM
> Emil Dotchevski wrote:
>> On Tue, Feb 17, 2009 at 2:34 PM, Steven Watanabe
>> <watanabesj_at_[hidden]> wrote:
>> > Emil Dotchevski wrote:
>> >>
>> >> The two approaches are:
>> >>
>> >> 1) Define a "to_string" interface and a separate, independent
>> >> "from_string" interface
>> >>
>> >> 2) Define a single interface that can go to and from string
>> >>
>> >> The second approach introduces coupling between to_string and
>> >> from_string. This coupling must be justified, you need to get
>> >> something in return. The only "something" I see here is
>> that it lets
>> >> you write code which doesn't "know" if it's going "to" or "from"
>> >> string.
>
> The coupling is not of implementation but of interface.  They are opposite sides of a single coin, so coupling them is not a terrible thing.

Many times I've needed to_string without needing from_string. In my
book, this is a strong indication that they shouldn't be coupled.

> The directionality you see is due to focusing on string with the other things converting to and from strings.  If, instead, you view it as converting from one thing to another, where string can be the source or destination type, then all conversions are, effectively, one way.

Yes, I agree that we can lead the discussion from this point of view.
In this case we must forget about strings and talk about converting
between all kinds of different types. You can't just say "it's not
specifically about strings" and be done with it; we have to consider
several different use cases in particular, as well as the issue in
general; how the conversion works, how you configure it, etc. Instead,
the whole thing even resides in a string namespace. :)

Because nobody seems to be doing this, I don't see any evidence that
the convert() function we could presumably end up with is any good for
anything but converting to- and from- strings. And for that use case
it's inferior to two independent to-string/from-string interfaces.

>> > The only other benefit, is possible syntactic nicity.  Note that
>> > this function can be in a very light weight header that forwards
>> > to the correct implementation, so the coupling would be minimal.
>>
>> Your description is identical to 1) as far as I'm concerned because
>> there is no coupling between to_string and from_string (the coupling
>> is between convert() and to_string/from_string). However, in this
>
> Indeed, conversion to string is implemented apart from conversion from string, but that hardly necessitates total separation.

What necessitates total separation then?

>> design it makes sense convert() to be a separate library altogether,
>> assuming it's scope goes beyond string conversions alone.
>
> It may well be, as I previously suggested, that there is an underlying set of functions for converting to strings and from strings to which convert defers.  That would permit you to get your preferred interface while others could use a more generic convert() interface, provided both were documented.

OK here we agree then. Let's come up with good interface for to-string
and from-string, and then feel free to propose a separate convert()
library.

Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode