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.
