Each class is derived from Object and object implements's a methode toString. But this method is crap, as it allways returns "Object" if it's not overloaded. In Java you can do the same, but there you get the mangled name of the class, which is much more usefull, as you can directly see, where you forgot to implement toString.

In article <buu2e9$1oav$1@digitaldaemon.com>, der Held says...
>
>Each class is derived from Object and object implements's a methode toString. But this method is crap, as it allways returns "Object" if it's not overloaded. In Java you can do the same, but there you get the mangled name of the class, which is much more usefull, as you can directly see, where you forgot to implement toString.
>
>

what he said

He said:

    class Object {
        char[] toString() {
            return this.classinfo.name;
        }
    }

is better than

    class Object {
        char[] toString() {
            return "Object";
        }
    }

"imr1984" <imr1984_member@pathlink.com> wrote in message news:buu988$22qq$1@digitaldaemon.com...
> In article <buu2e9$1oav$1@digitaldaemon.com>, der Held says...
> >
> >Each class is derived from Object and object implements's a methode
toString.
> >But this method is crap, as it allways returns "Object" if it's not
overloaded.
> >In Java you can do the same, but there you get the mangled name of the
class,
> >which is much more usefull, as you can directly see, where you forgot to implement toString.
> >
> >
>
> what he said
>
>

I think it's unnecessary that Object class has toString.
Maybe, we use flat toString of std.math2, std.date, std.string or etc more
than Object.toString,
and Object.toString was small hindrance on writing my class's method.
Also, most of classes don't need toString.

It's probably smart that move toString from Object class to new interface.

interface Showable
{
  char[] toString();
}

YT

"der Held" <der_member@pathlink.com> wrote in message news:buu2e9$1oav$1@digitaldaemon.com...
> Each class is derived from Object and object implements's a methode
toString.
> But this method is crap, as it allways returns "Object" if it's not
overloaded.
> In Java you can do the same, but there you get the mangled name of the
class,
> which is much more usefull, as you can directly see, where you forgot to implement toString.
>
>

In article <buuaj1$24vc$1@digitaldaemon.com>, Robert says...
>
>He said:
>
>    class Object {
>        char[] toString() {
>            return this.classinfo.name;
>        }
>    }
>
>is better than
>
>    class Object {
>        char[] toString() {
>            return "Object";
>        }
>    }
>
>"imr1984" <imr1984_member@pathlink.com> wrote in message news:buu988$22qq$1@digitaldaemon.com...
>> In article <buu2e9$1oav$1@digitaldaemon.com>, der Held says...
>> >
>> >Each class is derived from Object and object implements's a methode
>toString.
>> >But this method is crap, as it allways returns "Object" if it's not
>overloaded.
>> >In Java you can do the same, but there you get the mangled name of the
>class,
>> >which is much more usefull, as you can directly see, where you forgot to implement toString.
>> >
>> >
>>
>> what he said
>>
>>
>

i know what he said, i was dittoing it

Y.Tomino wrote:

> I think it's unnecessary that Object class has toString.
> Maybe, we use flat toString of std.math2, std.date, std.string or etc more
> than Object.toString,
> and Object.toString was small hindrance on writing my class's method.
> Also, most of classes don't need toString.
> 
> It's probably smart that move toString from Object class to new interface.
> 
> interface Showable
> {
>   char[] toString();
> }

I feel I must agree here, though to nitpick I believe 'Serializable' would be a more appropriate interface name. Not all classes are serializable. If you have a File class, you can return the contents as a string - very useful, because you now have a standard way to serialize a serializable object, which can be used in functions/methods that process strings, like for example CRC32(File.toString). But what about if you have a RNG class (random number generator)? How would you serialize that? Or what if you're a programmer that swears to OO like it was the best thing since sliced bread, and therefore implemented pretty much everything as an object... How then would you serialize the Parser object of a symbolic calculator?

Being capable of representing the object as a string only seems useful in some cases, and in others you'd generally just forget about implementing it. So why force a method onto every object, that only a subset of objects will need?

Is there actually a reason behind having toString in Object and not a separate interface? If so I'd like to hear it... I'm admittedly not a very experienced programmer (Walter was writing C++ compilers around the time I was born), so maybe I've missed out on some vital piece here, but as it is this implementation of toString() seems very illogical to me. It even smells of a foul bletcherous Javaism that needs to be sent into early retirement.

Sigbjørn Lund Olsen wrote:

> Is there actually a reason behind having toString in Object and not a separate interface? If so I'd like to hear it... I'm admittedly not a very experienced programmer (Walter was writing C++ compilers around the time I was born), so maybe I've missed out on some vital piece here, but as it is this implementation of toString() seems very illogical to me. It even smells of a foul bletcherous Javaism that needs to be sent into early retirement.

I think it is useful for templates.  You don't want to specialize every template for every object, just to be able to use the very common toString method (or equivalent). If you use an object that doesn't need toString it should just be an empty string, so nobody cares and everything still works.  toString is a very useful debugging tool.

-- 
-Anderson: http://badmama.com.au/~anderson/

J Anderson wrote:
> Sigbjørn Lund Olsen wrote:
> 
>> Is there actually a reason behind having toString in Object and not a separate interface? If so I'd like to hear it... I'm admittedly not a very experienced programmer (Walter was writing C++ compilers around the time I was born), so maybe I've missed out on some vital piece here, but as it is this implementation of toString() seems very illogical to me. It even smells of a foul bletcherous Javaism that needs to be sent into early retirement.
> 
> 
> I think it is useful for templates.  You don't want to specialize every template for every object, just to be able to use the very common toString method (or equivalent). If you use an object that doesn't need toString it should just be an empty string, so nobody cares and everything still works.  toString is a very useful debugging tool.
> 

I don't know much about templates, so correct me if I'm wrong... I'm thinking that what you're saying is you  use the toString() method of the object of type T passed to your template in the template code?

Now, I've always thought that toString() is meant to output a serialized / human readable representation of the data. Certainly the idea of naming the method toString() implies this is a conversion of data, and not some reportStatus() or getDebugInfo() of sorts. Using the same method for several different things (or having the same method unused sometimes) doesn't seem coherent to me, though that's purely aesthetical. But it would mean that you could not implicitly trust an object's toString() to necessarily give you what you want.

If you have an interface that defines toString() to output a serialized version of the object, then you would know what to expect from a toString(). Furthermore, you would not have to specialize for *every* object. You would have template FooTemplate(T){...} for every non-serializable object, and then FooTemplate(T : SerializableInterface){...} for all the serializable objects. Disclaimer: I'm assuming one can use an interface polymorphically. I don't know if this is the case in D. Is it the case?

Debug strings for objects are useful, no doubt - but wouldn't it be better to have that in for example a debugString() method inherited from Object, that by default printed the instanced' class name + a hash code, unless overridden? One could put that in a versioning block that would turn it off in a release build, as well. And it would give toString() a clearly defined meaning and use.

In fact, while I'm at it, one might want to have toString() be defined as anything that one wanted to put in an output stream, ie human readable and preferably short, rather than a serializable representation of the object, using serialize() defined by a SerializableInterface for that instead. It would still be wrong, imho, to assume that *every* object that could possibly exist, should have a human readable string representation, in the same way that it is wrong to assume that every object is serializable. On the other hand, it's right to assume that every object has a classname.

Cheers,
Sigbjørn Lund Olsen

> Is there actually a reason behind having toString in Object and not a separate interface? If so I'd like to hear it... 
Debugging is my favourite - admittedly this won't work nearly so well in D anyway without some language support for it (concatenation with strings or something), but being able to do
System.out.println("A: "+a+" B: "+b);
or in D
stdout.printf("%.*s","A: "~a~" B: "~b~"\n");
or even
stdout.printf("A: %o B: %o\n",a,b);
if there was a decent way of implementing that (in java everything is, or being is to, an object).
This generally gives you some information about an object in a consistent way, and if not at least gives you its class and some information to distinguish instances (in java you get Classname@Hashcode by default. In C# you get just Classname, and it's not as useful).
Anyway, in this case it's important that it's in the base class so that you always get something useful, and can override it to make it more useful.
Sam

Sigbjørn Lund Olsen wrote:

> J Anderson wrote:
>
>> Sigbjørn Lund Olsen wrote:
>>
>>> Is there actually a reason behind having toString in Object and not a separate interface? If so I'd like to hear it... I'm admittedly not a very experienced programmer (Walter was writing C++ compilers around the time I was born), so maybe I've missed out on some vital piece here, but as it is this implementation of toString() seems very illogical to me. It even smells of a foul bletcherous Javaism that needs to be sent into early retirement.
>>
>>
>>
>> I think it is useful for templates.  You don't want to specialize every template for every object, just to be able to use the very common toString method (or equivalent). If you use an object that doesn't need toString it should just be an empty string, so nobody cares and everything still works.  toString is a very useful debugging tool.
>>
>
> I don't know much about templates, so correct me if I'm wrong... I'm thinking that what you're saying is you  use the toString() method of the object of type T passed to your template in the template code?
>
> Now, I've always thought that toString() is meant to output a serialized / human readable representation of the data. Certainly the idea of naming the method toString() implies this is a conversion of data, and not some reportStatus() or getDebugInfo() of sorts. Using the same method for several different things (or having the same method unused sometimes) doesn't seem coherent to me, though that's purely aesthetical. But it would mean that you could not implicitly trust an object's toString() to necessarily give you what you want.
>
> If you have an interface that defines toString() to output a serialized version of the object, then you would know what to expect from a toString(). Furthermore, you would not have to specialize for *every* object. You would have template FooTemplate(T){...} for every non-serializable object, and then FooTemplate(T : SerializableInterface){...} for all the serializable objects. Disclaimer: I'm assuming one can use an interface polymorphically. I don't know if this is the case in D. Is it the case?
>
> Debug strings for objects are useful, no doubt - but wouldn't it be better to have that in for example a debugString() method inherited from Object, that by default printed the instanced' class name + a hash code, unless overridden? One could put that in a versioning block that would turn it off in a release build, as well. And it would give toString() a clearly defined meaning and use.
>
> In fact, while I'm at it, one might want to have toString() be defined as anything that one wanted to put in an output stream, ie human readable and preferably short, rather than a serializable representation of the object, using serialize() defined by a SerializableInterface for that instead. It would still be wrong, imho, to assume that *every* object that could possibly exist, should have a human readable string representation, in the same way that it is wrong to assume that every object is serializable. On the other hand, it's right to assume that every object has a classname.
>
> Cheers,
> Sigbjørn Lund Olsen


Data is data if it can't be in a human readable form then output the numbers.  I think serialization should be much easier. Users shouldn't need to write code to have an object serialized.  Most of the time the toString representation of an object is no good for serialization, because its bloated. Serial code is better as binary.

-- 
-Anderson: http://badmama.com.au/~anderson/