What are the original reasons for ToString() in Java and .NET?

Question

I've used ToString() modestly in the past and I've found it very useful in many circumstances. However, my usage of this method would hardly justify to put this method in none other than System.Object. My wild guess is that, at some point during the work carried out and meetings held to come up with the initial design of the .NET framework, it was decided that it was necessary - or at least extremely useful - to include a ToString() method that would be implemented by everything in the .NET framework.

Does anyone know what the exact reasons were? Am I missing a ton of situations where ToString() proves useful enough as to be part of System.Object? What were the original reasons for ToString()?

Thanks a lot!

PS - Again: I'm not questioning the method or implying that it's not useful, I'm just curious to know what makes it SO useful as to be placed in System.Object.

Side note - Imagine this:

AnyDotNetNativeClass someInitialObject = new AnyDotNetNativeClass([some constructor parameters]);

AnyDotNetNativeClass initialObjectFullCopy = AnyDotNetNativeClass.FromString(someInitialObject.ToString());

Wouldn't this be cool?

EDIT(1):

(A) - Based on some answers, it seems that .NET languages inherited this from Java. So, I'm adding "Java" to the subject and to the tags as well. If someone knows the reasons why this was implemented in Java then please shed some light!

(B) - Static hypothetical FromString vs Serialization: sure, but that's quite a different story, right?

Answer 1

It was initially added to Object for debugging and logging purposes. You can deduce this if you look at the JavaDoc for Object.toString (http://java.sun.com/javase/6/docs/api/java/lang/Object.html#toString()), as it outputs the classname, followed by @, followed by the unsigned hexadecimal representation of the hash code of the object. The only place I can see this being very useful is in a log or console.

But the Java creators intentionally left this method non-final so subclasses could (and should) override it to instead output more subclass-specific information. They could have just implemented the JVM such that passing an object into any method that required a string, it would generate that hash value above and pass it into the method, but instead they were nice and implemented it as a method that you could so conveniently override.

And its implemented at the Object level so they you can safely assume any object can be written out to a log/console. Its a convenient assumption in the Java language.

Answer 2

Without discussing its merits, I believe this has its roots in the inspirational language for C# - Java. The reason it was created (for both languages) was to provide a way to get a string representation of an instance of any object, including support for different cultures. Simple as that.

Answer 3

I can think of two technical reasons for defining toString() on java.lang.Object.

• The PrintStream.print(Object) API (for example) depends on Object.toString();

• The String concatenation operator + depends on Object.toString() in the case where one of the operands is a non-String reference type.

As an alternative, it would have been possible to define an interface (say) Printable that offered a toString()-like method and defined the above to require a Printable. (And that would avoid the puzzlement that arises when a newbie tries to print an object that doesn't overload toString()).

However, it is really convenient that print (etc) and + concatenation just work for everything. And I'm sure that's why Java was designed that way.

EDIT - in response to this followup question from the OP:

Static hypothetical FromString vs Serialization: sure, but that's quite a different story, right?

Assuming that I am parsing your syntax correctly ...

The goal of Object serialization is to provide a flat representation that can be reliably and efficiently deserialized. The goal of toString() is to provide a textual representation that is easy to read. In practice, "easy to read" and "reliably and efficiently deserializable" are contradictory.

Answer 4

I guess it was just considered useful that any object can have a string representation, if only for debugging purposes...