On 21/11/2010 17:21, Don wrote:
spir wrote:
On Sun, 21 Nov 2010 03:17:57 -0800
Jonathan M Davis <jmdavisp...@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?
Anyway, I cannot see any advantage in deprecating toString() for every
programmer in every use case, just for hypothetical efficiency issues
The efficiency issues are important, but are not the primary motivation.
toString() is just wrong. The idea that there is ONE AND ONLY ONE
textual representation of an object, is, frankly, idiotic.
That idea is quite idiotic indeed, no question about it. However, that
is not toString() 's idea! The point of toString (at least across
languages, not D specifically) is to provide a *default* representation
of a type.
It doesn't preclude other representations, and if format&friends
(writef, etc.), don't provide an integrated way to create/write a string
using custom formats for a given object/struct, that is format's
problem, it is not toString's fault.
One might ask, well, is toString any use then? Yes, very much, the idea
to provide a *default* representation of an object/struct is quite
useful. There are many situations where one would want to print a string
of an object without specifying any particular format. In fact, there
are some situations where specifying a particular format would not even
be possible or make sense, for example, when the code doesn't know the
exact type of the underlying object/struct (and thus not know what
formats are supported). Like a container printing its elements. Another
example I take from Java, it doesn't apply that much to D (at least not
at the moment), but still I want to point it out: toString() is used
extensively by the integrated debugger in JDT to print representations
of objects in views, popups, etc..
In fact, I think that coding only a default toString for a type may be
more common than otherwise (coding a toString that actually uses the
format specifiers). The string based format specifier is just not that
common outside of numerical types.
The question remains, if toString should support a format specifier or
not. I think it shouldn't, if there is an alternative satisfactorily
solution for numerical types and format&friends.
--
Bruno Medeiros - Software Engineer