I'm pretty sure most of the "debug" functions in the internal classes such as Object will be removed at 1.0, but just to make sure, will Object.toString() be removed?  The same information is available through Object.classinfo.name, and it's really irritating to have to type "std.string.toString" every time I want to use toString() in a class member function.

In article <cv902c$1jit$1@digitaldaemon.com>, Jarrett Billingsley says...
>
>I'm pretty sure most of the "debug" functions in the internal classes such as Object will be removed at 1.0, but just to make sure, will Object.toString() be removed?  The same information is available through Object.classinfo.name, and it's really irritating to have to type "std.string.toString" every time I want to use toString() in a class member function.

you can use just .toString to get the toString at module scope instead of the
class toString:
# import std.string;
# class foo {
#   void bar() { .toString(10); }
#   char[] toString(){ return "foo"; }
# }
# int main() { return 0; }

Also Object.clasinfo.name cannot be overridden like toString can be, so the two have pretty different behaviors.

-Ben

> you can use just .toString to get the toString at module scope instead of
> the
> class toString:

Forgot about the global scope operator.  Thanks!

> Also Object.clasinfo.name cannot be overridden like toString can be, so
> the two
> have pretty different behaviors.

Well what's the point in having Object.toString() in the first place?  It can be overridden, so what?  It's supposed to return the classinfo.name, and nothing else.  So what's the purpose?

>> Also Object.clasinfo.name cannot be overridden like toString can be, so the two have pretty different behaviors.
>
>Well what's the point in having Object.toString() in the first place?  It can be overridden, so what?  It's supposed to return the classinfo.name, and nothing else.  So what's the purpose?

Why do you say it is supposed to always return classinfo.name?
My guess is that toString in D is supposed to be like toString in Java and C#
and in those languages toString returns a human-readable summary of the object.
Personally I'd like D's Object.toString to include a unique id as well as the
class name so that you can tell one object apart from another. Without that I
still have to rely on code like
printf("obj is %x\n",obj);
instead of
writefln("obj is ", obj);

Jarrett Billingsley wrote:
> Well what's the point in having Object.toString() in the first place?  It can be overridden, so what?  It's supposed to return the classinfo.name, and 
I've never seen that.  In fact, I frequently use it for other things.

> nothing else.  So what's the purpose? 

I believe when one does something like:
Object o = ....
writefln("%s", o);

format is supposed to call the toString method and use that.

John

Ben Hinkle wrote:

> Personally I'd like D's Object.toString to include a unique id as well as the
> class name so that you can tell one object apart from another. Without that I
> still have to rely on code like
> printf("obj is %x\n",obj);
> instead of
> writefln("obj is ", obj);

I second that, it would be nice if it worked like in Java for instance:

> The toString method for class Object returns a string consisting of the
> name of the class of which the object is an instance, the at-sign
> character `@', and the unsigned hexadecimal representation of the hash
> code of the object.

Sample D implementation:

>     char[] toString()
>     {
> 	return std.string.format("%d@%x", this.classinfo.name, this.toHash());
>     }

Optionally it could use the pointer/reference, instead of the hashcode ?

--anders

> Sample D implementation:
> 
>>     char[] toString()
>>     {
>>     return std.string.format("%d@%x", this.classinfo.name, this.toHash());
>>     }

I meant to write "%s@%x", but for some reason the above worked ?

--anders

> My guess is that toString in D is supposed to be like toString in Java and
> C#
> and in those languages toString returns a human-readable summary of the
> object.

I suppose that'd be fine, but wouldn't it make more sense to put that kind of stuff in the typeinfo?

> Personally I'd like D's Object.toString to include a unique id as well as
> the
> class name so that you can tell one object apart from another.

Might be a bit tricky.  If by "unique ID" (I have never used Java so I have no idea what its ID numbers are) you mean some kind of ID number that is assigned incrementally to each newly allocated object (so the first one has an ID of 1, the next has 2, and so on), I'm not real sure how easy that'd be to implement it as part of the language.  Or how practical.  If by ID you mean a hash.. well, that'd be nice if the toHash() method did more than return an int representation of the pointer ;)

Jarrett Billingsley wrote:

> Might be a bit tricky.  If by "unique ID" (I have never used Java so I have no idea what its ID numbers are) you mean some kind of ID number that is assigned incrementally to each newly allocated object (so the first one has an ID of 1, the next has 2, and so on), I'm not real sure how easy that'd be to implement it as part of the language.  Or how practical.  If by ID you mean a hash.. well, that'd be nice if the toHash() method did more than return an int representation of the pointer ;) 

Java uses the hash code, and they tend to look somewhat similar:

o.java:
> public class o
> {
>   public static void main(String[] args)
>   {
>     Object o = new Object();
>     System.out.println(o);
>   }
> }

java.lang.Object@47b480

o.d:
> import std.stdio;
> 
> char[] toString(Object o)
> {
>   return std.string.format("%s@%x", o.classinfo.name, o.toHash());
> }
> 
> void main()
> {
>   Object o = new Object();
>   writefln("%s", toString(o));
> }

Object@406fe0


And the default toHash will not just return the pointer forever:

internal/object.d:
> // BUG: this prevents a compacting GC from working, needs to be fixed

So just because the *current* implementation of toString() or toHash()
returns something, doesn't mean it's identical to that implementation ?

--anders

PS. You should take a quick peek at Java, if you haven't already.
    D is something of a cross-over language between C and Java...

In article <cvcmkd$2nc5$1@digitaldaemon.com>, Jarrett Billingsley says...
>
>> My guess is that toString in D is supposed to be like toString in Java and
>> C#
>> and in those languages toString returns a human-readable summary of the
>> object.
>
>I suppose that'd be fine, but wouldn't it make more sense to put that kind of stuff in the typeinfo?

The summary should contain information about the instance, too. For example "[FooClass@1234abcd x:33 y:66 flag:false]". In order to create the string you have to run a function. It could be possible to put a slot in the classinfo and have users call that whenever they need the string but using a vtable slot is pretty much the same functionality and is the standard way to allow class objects to customize behavior.

>> Personally I'd like D's Object.toString to include a unique id as well as
>> the
>> class name so that you can tell one object apart from another.
>
>Might be a bit tricky.  If by "unique ID" (I have never used Java so I have no idea what its ID numbers are) you mean some kind of ID number that is assigned incrementally to each newly allocated object (so the first one has an ID of 1, the next has 2, and so on), I'm not real sure how easy that'd be to implement it as part of the language.  Or how practical.  If by ID you mean a hash.. well, that'd be nice if the toHash() method did more than return an int representation of the pointer ;)

I had forgotten exactly what the id is that Java prints. Looking at the Java doc the string contains the hash code as hex. I guess that sacrifices guaranteed uniqueness but makes it easy to write toString. Since the hash code is probably the pointer in Java as well as D it is pretty much the same as printing out the address. I don't know what Java implementations with copying collectors do.