Semantics of toString

Don nospam at nospam.com
Wed Nov 11 07:18:41 PST 2009


Bill Baxter wrote:
> On Tue, Nov 10, 2009 at 5:27 PM, Andrei Alexandrescu
> <SeeWebsiteForEmail at erdani.org> wrote:
>> Bill Baxter wrote:
>>> 2009/11/10 Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org>:
>>>> Denis Koroskin wrote:
>>>>> On Wed, 11 Nov 2009 02:49:54 +0300, Andrei Alexandrescu
>>>>> <SeeWebsiteForEmail at 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");





More information about the Digitalmars-d mailing list