DIP9 -- Redo toString API

[Dmitry Olshansky]

On 21.11.2010 17:08, spir wrote:
> On Sun, 21 Nov 2010 03:17:57 -0800
> Jonathan M Davis<jmdavisProg at gmx.com>  wrote:
>
>> You're not losing _anything_ out of the deal except that you wouldn't do
>> obj.toString(). Instead you'd do to!string(obj).
> I'm usually not using toString(), it's supported by the language. What about format("%s:%s", a,b)? Will it still call toString implicitely, or writeTo a buffer, or what else?
toString is supported by the library, not the language. In fact, format 
may use whatever it wishes inside, as long as the net result is the same.
> Anyway, I cannot see any advantage in deprecating toString() for every programmer in every use case, just for hypothetical efficiency issues -- that have not yet been shown in concrete cases: an app that cannot work fine because of toString allocating on the heap. Let us free to use our favorite tools, please! Do not pretend&  telling us what is best for us.
As you said, you never use toString directly, why would you care if your 
apps just got a slight overall speed up in text I/O ?
The only thing is to change the overridden method in your 
classes/structs, and besides your favorite toString is going to be 
supported for sometime.
And allocating string on heap *is* an impact on performance when you 
want to print custom collections (and mind you, they can be quite long) 
in human-readable form.
> The solution is simple: toString() defaults to writeTo, writeTo defaults to toString. This also solves 2 "human" issue you evoke: that people are used to toString and know it very well, and that writeTo looks more intimidating.
Meaningless.
> As said in previous post, enhancing toString with a format specifier would be cool.
>
> Denis
> -- -- -- -- -- -- --
> vit esse estrany ☣
>
> spir.wikidot.com
>


-- 
Dmitry Olshansky