DIP9 -- Redo toString API
Michel Fortin
michel.fortin at michelf.com
Sun Nov 21 06:38:58 PST 2010
On 2010-11-21 05:10:13 -0500, spir <denis.spir at gmail.com> said:
> I consider time & space efficiency for string output to be irrelevant, not
> even a theoretic question. Maybe I simply have never reached points where i
> t would? Have you ever stepped on a app not running correctly because toStr
> ing 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 feedb
> ack -- user interface requires far more sophisticated, and in most case cus
> tom, tools. Who cares how much memory or time is required? Memory is eventu
> ally 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 buff
> er vs file vs terminal).
I felt like that at first too. I like the simplicity of toString and
though that perhaps both writeTo and toString should be allowed to
coexist peacefully.
But then I came to this realization: toString is almost like a language
feature. And as a very visible idiom, it should set the example. If you
show people toString functions with a signature that force needless
allocations, they're going to reproduce the pattern for other things
where they shouldn't. I think toString, or rather writeTo, should be a
showcase of good practice, and thus I'm in favor of deprecating
toString to increase exposure to the better idiom.
Is this going to startle some people? Probably. But then perhaps
they'll take a closer look and understand the design has its advantages
and reuse it elsewhere.
--
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/
More information about the Digitalmars-d
mailing list