DIP9 -- Redo toString API

[Bruno Medeiros]

On 07/12/2010 17:31, Steven Schveighoffer wrote:
> On Tue, 07 Dec 2010 11:44:56 -0500, Bruno Medeiros
> <brunodomedeiros+spam at com.gmail> wrote:
>
>> On 02/12/2010 21:08, Steven Schveighoffer wrote:
>>> On Thu, 02 Dec 2010 11:31:49 -0500, Bruno Medeiros
>>> <brunodomedeiros+spam at com.gmail> wrote:
>>>
>>>> On 21/11/2010 17:21, Don wrote:
>>>>
>>>> That idea is quite idiotic indeed, no question about it. However, that
>>>> is not toString() 's idea! The point of toString (at least across
>>>> languages, not D specifically) is to provide a *default*
>>>> representation of a type.
>>>>
>>>> It doesn't preclude other representations, and if format&friends
>>>> (writef, etc.), don't provide an integrated way to create/write a
>>>> string using custom formats for a given object/struct, that is
>>>> format's problem, it is not toString's fault.
>>>
>>> to!string(x) will handle what toString does now.
>>>
>>
>> So? What was the point here, I didn't get it.
>
> The point is, we don't need a toString method *and* a formatted output
> method. The toString method is replaced by the formatted output method
> in the proposal (writeTo), which already contains a format specifier.
>
>>
>>>> In fact, I think that coding only a default toString for a type may be
>>>> more common than otherwise (coding a toString that actually uses the
>>>> format specifiers). The string based format specifier is just not that
>>>> common outside of numerical types.
>>>
>>> You can ignore the format specifier if you want to.
>>>
>>> -Steve
>>
>> For calling toString, yes, you can ignore it. But as for defining the
>> toString method, not entirely, you still have to write the format
>> parameter (", string format = null"). After that it won't hinder you
>> in any way, it will just be unnecessary visual baggage.
>
> Yes, that is my point.
>
>> So the downside of having to write that extra parameter is incredibly
>> low, it is merely aesthetic (plus the initial one-off impact of people
>> learning what the format parameter is for).
>> However, toString is a core part of the language, and a very common to
>> define, and if D were to gain more mainstream usage, I worry that
>> something like 98% (or something like that) of all toStrings would not
>> use format, so it seems like a bit of a waste.
>>
>> It is not an issue I care that much about, only a little bit.
>
> In the proposal, toString is removed, only writeTo would exist (which
> has formatting support). I guess I don't really understand what you are
> asking for. I interpreted your posts as requests that we don't
> change/deprecate toString, is that not the case?
>
> -Steve

No, that wasn't the case at all. Looking back, it's partially my fault I 
wasn't clear on that. I was disagreeing with Don's "The idea that there 
is ONE AND ONLY ONE textual representation of an object, is, frankly, 
idiotic" , but it wasn't to support spir's argument "I cannot see any 
advantage in deprecating toString()". I'm fine with D's current toString 
to be removed/deprecated, or made into a final method that calls writeTo 
(slightly prefer last alternative).

Also, I kept mentioning "toString" and not "writeTo" in my posts because 
I started by talking generically of the string-representation mechanism 
across languages, not about D specifically.
Actually, this brings me to another beef I have with the proposal (kinda 
bikeshed, but still a bit significant): the new "writeTo" method should 
have string somewhere in the name. So, like "writeString", or 
"writeStringTo", or something like that. If it's about strings, it 
should have string in the signature. Even more so because "writeTo" is a 
very generic name, it might cause a bit of confusion with socket or 
serialization kinds of classes.


-- 
Bruno Medeiros - Software Engineer