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




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 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




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
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


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
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... 


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 

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