www.digitalmars.com         C & C++   DMDScript  

D - Object's toString

reply der Held <der_member pathlink.com> writes:
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.
Jan 24 2004
next sibling parent reply imr1984 <imr1984_member pathlink.com> writes:
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
Jan 24 2004
parent reply "Robert" <no spam.ne.jp> writes:
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


But this method is crap, as it allways returns "Object" if it's not


In Java you can do the same, but there you get the mangled name of the


which is much more usefull, as you can directly see, where you forgot to
implement toString.

what he said

Jan 24 2004
parent imr1984 <imr1984_member pathlink.com> writes:
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


But this method is crap, as it allways returns "Object" if it's not


In Java you can do the same, but there you get the mangled name of the


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
Jan 24 2004
prev sibling parent reply "Y.Tomino" <demoonlit inter7.jp> writes:
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

 But this method is crap, as it allways returns "Object" if it's not

 In Java you can do the same, but there you get the mangled name of the

 which is much more usefull, as you can directly see, where you forgot to
 implement toString.

Jan 24 2004
parent reply =?UTF-8?B?U2lnYmrDuHJuIEx1bmQgT2xzZW4=?= <sigbjorn lundolsen.net> writes:
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.
Feb 23 2004
next sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
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/
Feb 23 2004
parent reply =?ISO-8859-1?Q?Sigbj=F8rn_Lund_Olsen?= <sigbjorn lundolsen.net> writes:
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
Feb 23 2004
parent J Anderson <REMOVEanderson badmama.com.au> writes:
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/
Feb 23 2004
prev sibling next sibling parent Sam McCall <tunah.d tunah.net> writes:
 Is there actually a reason behind having toString in Object and not a 
 separate interface? If so I'd like to hear it... 

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
Feb 23 2004
prev sibling parent Derek Parnell <Derek.Parnell Psyc.ward> writes:
On Mon, 23 Feb 2004 16:58:03 +0100 (02/24/04 02:58:03)
, Sigbjørn Lund Olsen <sigbjorn lundolsen.net> wrote:

 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.

I understand serialization to be a way of creating a snapshot of an object's 'state', commonly done in a human readable format. In theory, one could recreate the state of an object from the serialized data. This covers simple case of converting some objects to a string form based on their current data value(s). It also could apply to a RNG, to record the current seed, and other values used in generating the next random number. It could apply to a Parser object to record the internal state of the parser at a specific moment in time. As such, it could be used as a debugging tool as well (along with other things). -- Derek -- Derek
Feb 23 2004