Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Never Use toString() for Behaviour

java.christmas

Post reply on HN
Print view View original

11–20 of 51 posts

Re: Never Use toString() for Behaviour

#11

Post by simendsjo »

netsharc wrote: post #7
kasperni wrote: 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.

More like "beginning software architecture". While this is "common knowledge" after coding for years, it's actually hard-earned, battle-scarred knowledge. Sharing experience on how to design software is very useful for all the people just starting out.

Re: Never Use toString() for Behaviour

#14

Post by kanox »

mrkeen wrote: post #13

Never use a language that puts a toString() implementation on every object regardless of whether or not that object implements toString()

The ability to convert any object to a string is very useful for debugging and most languages support this. Even in C it's frequently useful to print %p to identify objects.

Serialization should require involve separate APIs.

Re: Never Use toString() for Behaviour

#15

Post by drainyard »

kanox wrote: post #14
mrkeen wrote: post #13

Never use a language that puts a toString() implementation on every object regardless of whether or not that object implements toString()

The ability to convert any object to a string is very useful for debugging and most languages support this. Even in C it's frequently useful to print %p to identify objects. Serialization should require involve separate APIs.

It should be opt-in though. A compiler-flag for debug builds or similar.

Re: Never Use toString() for Behaviour

#16

Post by ThePadawan »

kanox wrote: post #14
mrkeen wrote: post #13

Never use a language that puts a toString() implementation on every object regardless of whether or not that object implements toString()

The ability to convert any object to a string is very useful for debugging and most languages support this. Even in C it's frequently useful to print %p to identify objects. Serialization should require involve separate APIs.

Which is why C# (and apparently other .NET constituents) has the excellent, but separate DebuggerDisplay API [0]. IIRC it also makes it possible to define a private implementation to communicate to clients that this pseudo-serialization is not part of the public API (like ToString() implicitly would be).

[0] https://docs.microsoft.com/en-us/visualstudio/debugger/using...

Re: Never Use toString() for Behaviour

#17

Post by chris_overseas »

drainyard wrote: post #15
kanox wrote: post #14

Earlier quoted context omitted.

The ability to convert any object to a string is very useful for debugging and most languages support this. Even in C it's frequently useful to print %p to identify objects. Serialization should require involve separate APIs.

It should be opt-in though. A compiler-flag for debug builds or similar.

Why so, what are the downsides? It's not like it introduces any meaningful overhead at all, and there are plenty of situations where it is useful even in production (eg for logging in catchall "can't happen" top level exception handlers). Adding yet another compiler flag seems like a worse solution to me.

Re: Never Use toString() for Behaviour

#18

Post by mrkeen »

chris_overseas wrote: post #17
drainyard wrote: post #15

Earlier quoted context omitted.

It should be opt-in though. A compiler-flag for debug builds or similar.

Why so, what are the downsides? It's not like it introduces any meaningful overhead at all, and there are plenty of situations where it is useful even in production (eg for logging in catchall "can't happen" top level exception handlers). Adding yet another compiler flag seems like a worse solution to me.

What you lose is the ability to model objects based on the behaviours that they can perform.

I want to be able to design objects that have toString() and I want to be able to design objects that don't have toString().

The same goes for clone(), hash(), getPtr(), getEndian(), equals(), toBytes(), toJson(), encrypt(), delete(), isNumeric(), toXml(), serializationVersion() or compare().

Re: Never Use toString() for Behaviour

#19

Post by bluesign »

> If you used the returned Country to construct an API request including the name of the country, this will now produce strange countries named as “Optional[“Norway”]”

I am not too familiar with java, but should’t you call get() from optional to get Country from Optional and toString of Country will behave as expected.

Re: Never Use toString() for Behaviour

#20

Post by iainmerrick »

bluesign wrote: post #19

> If you used the returned Country to construct an API request including the name of the country, this will now produce strange countries named as “Optional[“Norway”]” I am not too familiar with java, but should’t you call get() from optional to get Country from Optional and toString of Country will behave as expected.

The point is that if you change the type, existing calls to country.toString() will still compile. (Normally, fixing compile errors is a fairly reliable way to do this kind of refactoring.) That means you can’t guarantee to catch them all, so there’s a risk of modified behavior escaping into production.
Post reply on HN