Semantics of toString

[Don]

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.