Bill Baxter wrote:
On Tue, Nov 10, 2009 at 5:27 PM, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
Bill Baxter wrote:
2009/11/10 Andrei Alexandrescu <seewebsiteforem...@erdani.org>:
Denis Koroskin wrote:
On Wed, 11 Nov 2009 02:49:54 +0300, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
Don wrote:
Lutger wrote:
Don wrote:
...
There is a definite use for such as thing. But the existing
toString()
is much, much worse than useless. People think you can do something
with
it, but you can't.
eg, people have asked for BigInt to support toString(). That is an
over-my-dead-body.
Since you are in the know and probably the biggest toString() hater
around: are there plans (or rejections thereof) to change toString()
before
D2 turns gold? Seems to me it could break quite some code.
I'm hoping someone will come up with a design.
Straw man:
void toString(void delegate(const(char)[]) sink, string fmt) {
// fmt holds the format string from writefln/formatln.
// call sink() to print partial results.
}
I think the best option for toString is to take an output range and
write
to it. (The sink is a simplified range.)
Andrei
It means toString() must be either a template, or accept an abstract
InputRange interface?
It should take an interface.
So yet another type in object.d?
Or require users in import something specific in every module that's
going to use toString?
--bb
I am not sure. Opinions as always are welcome.
That's why my opinion is that the delegate idea is nice. :-)
But I guess toString is already defined by Object, right? So it would
make sense for an interface needed by an Object method to be defined
in object.d. I suppose it could be an interface defined inside the
Object class itself? (Does that work? can you define interfaces
inside classes?)
It also needs to be used by structs, which aren't inherited from Object.
So I don't see how a nested interface could work.
I suggest a design acceptance criterion: the simplest case should be
about as simple as:
return "xxx";
or
put("xxx");
