Semantics of toString

[Bill Baxter]

On Tue, Nov 10, 2009 at 2:51 AM, Don <nospam at nospam.com> wrote:
> Lutger wrote:
>>
>> Justin Johansson wrote:
>>
>>> Lutger Wrote:
>>>
>>>> Justin Johansson wrote:
>>>>
>>>>> I assert that the semantics of "toString" or similarly named/purposed
>>>>> methods/functions in many PL's (including and not limited to D) is
>>>>> ill-defined.
>>>>>
>>>>> To put this statement into perspective, I would be most appreciative of
>>>>> D NG readers responding with their own idea(s) of what the semantics of
>>>>> "toString" are (or should be) in a language agnostic ideology.
>>>>>
>>>> My other reply didn't take the language agnostic into account, sorry.
>>>>
>>>> Semantics of toString would depend on the object, I would think there
>>>> are
>>>> three general types of objects:
>>>>
>>>> 1. objects with only one sensible or one clear default string
>>>> representations, like integers. Maybe even none of these exist (except
>>>> strings themselves?)
>>>>
>>>> 2. objects that, given some formatting options or locale have a clear
>>>> string representation. floating points, dates, curreny and the like.
>>>>
>>>> 3. objects that have no sensible default representation.
>>>>
>>>> toString() would not make sense for 3) type objects and only for 2) type
>>>> objects as part of a formatting / localization package.
>>>>
>>>> toString() as a debugging aid sometimes doubles as a formatter for 1)
>>>> and
>>>> 2) class objects, but that may be more confusing than it's worth.
>>>>
>>> Thanks for that Lutger.
>>>
>>> Do you think it would make better sense if programming languages/their
>>> libraries separated functions/methods which are currently loosely
>>> purposed
>>> as "toString" into methods which are more specific to the types you
>>> suggest (leaving only the types/classifications and number thereof to
>>> argue about)?
>>>
>>> In my own D project, I've introduced a toDebugString method and left
>>> toString alone. There are times when I like D's default toString printing
>>> out the name of the object
>>> class.  For debug purposes there are times also when I like to see a
>>> string printed
>>> out in quotes so you can tell the difference between "123" and 123.  Then
>>> again, and since I'm working on a scripting language, sometimes I like to
>>> see debug output distinguish between different numeric types.
>>>
>>> Anyway going by the replies on this topic, looks like most people view
>>> toString as being good for debug purposes and that about it.
>>>
>>> Cheers
>>> Justin
>>>
>>
>> Your design makes better sense (to me at least) because it is based on why
>> you want a string from some object.
>> Take .NET for example: it does provide very elaborate and nice formatting
>> options based and toString() with parameters. For some types however, the
>> default toString() gives you the name of the type itself which is in no way
>> related to formatting an object. You learn to work with it, but I find it a
>> bit muddled.
>> As a last note, I think people view toString as a debug thing mostly
>> because it is very underpowered.
>
> There is a definite use for such as thing. But the existing toString() is
> much, much worse than useless. People think you can do something with it,
> but you can't.
> eg, people have asked for BigInt to support toString(). That is an
> over-my-dead-body.

You can definitely do something with it -- printf debugging.  And if I
were using BigInt, that's exactly why I'd want BigInt to have a
toString.  Just out of curiousity, how does someone print out the
value of a BigInt right now?

--bb