On Wed, Feb 18, 2009 at 5:52 AM, Stewart, Robert <Robert.Stewart@sig.com> wrote:
On Tuesday, February 17, 2009 5:43 PM Emil Dotchevski 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
On Tue, Feb 17, 2009 at 2:34 PM, Steven Watanabe <watanabesj@gmail.com> wrote: 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