Live data from Hacker News

Never Use toString() for Behaviour

java.christmas

1–10 of 51 posts

Re: Never Use toString() for Behaviour

#2
Agree in general, but note that Java itself does not follow this rule: StringBuilder's and StringWriter's toString methods use toString for behavior — creating a string from accumulated chars, and I'm fine with that.

Re: Never Use toString() for Behaviour

#5
>If left unoverridden, it only yields a description of it’s class and location in memory

It contains the hashCode(), not the memory location. The default implementation of hashCode could use a memory location to generate the hash, however that isn't the case in all implementations. OpenJDK seems to have used an RNG by default in the past and currently derives a value from the thread state[1]

[1]https://srvaroa.github.io/jvm/java/openjdk/biased-locking/20...

Re: Never Use toString() for Behaviour

#6
post #2

Agree in general, but note that Java itself does not follow this rule: StringBuilder's and StringWriter's toString methods use toString for behavior — creating a string from accumulated chars, and I'm fine with that.

This also definitely does not apply to .NET where there are many classes that override ToString for meaningful, well-documented behavior (StringBuilder is one, funnily enough). It's best to check the docs or look at IntelliSense before applying this rule in a blanket fashion.

That said, it does seem like Microsoft has since moved away from overriding ToString for such things. In all honesty, Object.ToString was probably a mistake to begin with.

Re: Never Use toString() for Behaviour

#7
post #3

That was a complete waste of time. To sum it up: don't rely on the format of a generic toString() method. Prefer country.getName() over country.toString(), even if toString() returns getName().

It's cool to read, but yeah, it's like reading Beginner's Java, lesson 3.

Re: Never Use toString() for Behaviour

#8
post #3

That was a complete waste of time. To sum it up: don't rely on the format of a generic toString() method. Prefer country.getName() over country.toString(), even if toString() returns getName().

> That was a complete waste of time.

I think that's a bit harsh. It's an article explaining simply, but effectively why you should probably not use toString(). Just because something can be summed up in a sentence does not make it a waste of time.

Re: Never Use toString() for Behaviour

#9
post #2

Agree in general, but note that Java itself does not follow this rule: StringBuilder's and StringWriter's toString methods use toString for behavior — creating a string from accumulated chars, and I'm fine with that.

This also definitely does not apply to .NET where there are many classes that override ToString for meaningful, well-documented behavior (StringBuilder is one, funnily enough). It's best to check the docs or look at IntelliSense before applying this rule in a blanket fashion. That said, it does seem like Microsoft has since moved away from overriding ToString for such things. In all honesty, Object.ToString was proba…

There's nothing wrong with returning something well-specified from toString, but I agree this should never be relied upon. And even if toString actually return something well-specified, the same functionality should be available as a distinct method.

Any form of (semi-)automatic SomeObject -> String should be treated as a convenience for the developer to avoid getting a non-descriptive memory location reported.

Having the automatic toString isn't the problem, but maybe the name of the method is. It could be called "asDebugHelpRepresentation" or something more descriptive.

Re: Never Use toString() for Behaviour

#10
post #3

That was a complete waste of time. To sum it up: don't rely on the format of a generic toString() method. Prefer country.getName() over country.toString(), even if toString() returns getName().

A complete waste of time for some, and very useful for others. I don't believe comments like this is constructive for anyone.
Post reply on HN