On 21.11.2010 17:08, spir wrote:
On Sun, 21 Nov 2010 03:17:57 -0800
Jonathan M Davis<[email protected]> 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
