DIP9 -- Redo toString API

Pelle Månsson pelle.mansson at gmail.com
Sun Nov 21 06:55:10 PST 2010


On 11/21/2010 11:10 AM, spir wrote:
> What I do not want is tostring be deprecated in any case. The proposal would be OK if it introduced an _alternative_ for the cases (?) where string output efficiency is relevant. The language could/should default to writeTo is toString is not defined, *and* conversely default to toString if writeTo is not defined. But in no way let down toString. Below quote of the DIP's relevant part.
> It is also, certainly, a very good idea to allow passing formatting data default textual expression routines; but I fail to see why deprecating tostring is necessary for that. Instead, it would certainly be a highly useful toString parameter in numerous cases.

Instead of

     return "something";

write

     sink("something");

You lose nothing. You do, however, gain the ability to output an object 
without concatenating a string over and over.

> I consider time&  space efficiency for string output to be irrelevant, not even a theoretic question. Maybe I simply have never reached points where it would? Have you ever stepped on a app not running correctly because toString allocates on the heap? Or is it random thoughts?
> First, as the proposal states, "Debug output is a common need when testing code or logging data." Most uses of such tools are for programmer own feedback -- user interface requires far more sophisticated, and in most case custom, tools. Who cares how much memory or time is required? Memory is eventually freed ayway, and output speed is not limited on the program side, but well by rendering computations and/or physical limits (try to write to buffer vs file vs terminal).
> Moreover, string output tasks often come last in a process chain -- that's what a programmer waits for to get useful information on program behaviour and be able to control, diagnose, compare...
>
> But the key point is that language features like D's toString are far to be used only for _direct_ string output. They are extremely useful for numerous tasks of string manipulation and processing, most of which again for programmer's own use. Sometimes, at the end of process chain comes string otuput -- but indirectly.

With this, it doesn't need to be. Instead of writing another function 
for non-debuglike string output, just use writeTo.


More information about the Digitalmars-d mailing list