views:

265

answers:

4

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?

+6  A: 

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.

Otávio Décio
Java has the same? Sorry, I've never done any Java at all...
d.
Sure does, but there it is called toString() - lowercase first letter.
Otávio Décio
That just means that the same question is relevant to Java.
Rune
Still the question is open. Why did Java desigers do it like this or the designers of whatever language Java took it from and why didn't they or the .NET designers change it.
Stilgar
+10 if I could, but I can't so I just up voted once :-)
fuzzy lollipop
@Rune - perhaps more even so.
Otávio Décio
+1. The question would be more relevant to ask in Java's case. I strongly suspect that C# and .NET simply added it because they needed to be Java-like. .NET, and `System.Object` has adopted a lot of cruft from Java in this way. Most of the members of `System.Object` class should never have been there.
jalf
@jalf - I agree, and not only toString bug hashCode found its way into c# object class.
Otávio Décio
hash code seems more obvious because you need it for dictionaries.
Stilgar
@Stilgar - I am not debating the merits of either, just C#'s borrowings from Java.
Otávio Décio
"including support for different cultures" - Can you show a Java example in which `toString` helps tell the difference between an Irish-speaking Irishman and an Euskara-speaking Spaniard? Or do you mean something else by "different cultures"? Thanks!
d.
As per MSDN(for C# - http://msdn.microsoft.com/en-us/library/system.object.tostring.aspx) This method returns a human-readable string that is culture-sensitive. For example, for an instance of the Double class whose value is zero, the implementation of Double.ToString might return "0.00" or "0,00" depending on the current UI culture.
Otávio Décio
But how about Java?
d.
I don't think Java has the same concern with internationalization as C# does.
Otávio Décio
jejeje.... roots in the *"inspirational"* language ...
OscarRyz
@Otavio - sure Java is concerned with internationalization; see ResourceBundle, NumberFormat, etc. It is just that `java.lang.Object.toString()` was and is primarily designed for debugging / logging ... NOT internationalization.
Stephen C
+1  A: 

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

Thomas Levesque
+8  A: 

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.

dhergert
+2  A: 

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.

Stephen C
Is there an echo in here? ;) Check my comment on the OP. Upvoted.
Merlyn Morgan-Graham
No echo. I wouldn't call a Printable-like interface "overkill". It is just the wrong solution, IMO.
Stephen C
"The goal of Object serialization...". Sure. Beside the point though.
d.
@d - didn't you read the OP's question "(B)" ???? He is (if I read his question correctly) asking if toString() / fromString() would be a viable alternative to object serialization. And my answer is, basically no.
Stephen C
Sorry - You're right.
d.