Never Use toString() for Behaviour • Hacker News Board

Re: Never Use toString() for Behaviour

#21

Post by kasperni » Wed, Dec 04, 2019, 2:05 PM UTC

simendsjo wrote: post #10

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().

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

Yeah, I was a bit harsh. But they already posted an announcement post about their Christmas calendar: https://news.ycombinator.com/item?id=21700759 I don't see the need to go into individual posts on top of it.

In the end, I just think there are better channels for getting started with programming in a particular language then this site.

Re: Never Use toString() for Behaviour

#22

Post by mrkeen » Wed, Dec 04, 2019, 2:27 PM UTC

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.

That %p approach sounds perfect.

If they wanted to make it worse, they could make it so you could call %s on any object, and if it wasn't defined, it would "conveniently" fall back to %p instead.

Then someone could could write an article called "Never Use %s for Behaviour"

Re: Never Use toString() for Behaviour

#23

Post by oftenwrong » Wed, Dec 04, 2019, 2:47 PM UTC

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.

As the sibling comment says, the post's advice is really about making your code refactoring-friendly with regard to type checking.

You generally would not want to call '.get()' without an 'isPresent()' check because it will throw a NoSuchElementException if the Optional is empty. This is a foreseeable case, so most would like to handle it somewhat explicitly.

Today, it is idiomatic to use '.map' to transform it:

    Optional foo = optionalCountry.map(Country::getName);

You can also throw a domain-specific exception from that point:

    Optional foo = optionalCountry
        .map(Country::getName)
        .orElseThrow(...);

Re: Never Use toString() for Behaviour

#24

Post by flerchin » Wed, Dec 04, 2019, 3:53 PM UTC

We use lombok, and the toString annotation is immensely helpful for logging and avoiding this type of thing.

Re: Never Use toString() for Behaviour

#25

Post by fahadkhan » Wed, Dec 04, 2019, 4:36 PM UTC

flerchin wrote: post #24

We use lombok, and the toString annotation is immensely helpful for logging and avoiding this type of thing.

How does Lombok help to avoid this?

Re: Never Use toString() for Behaviour

#26

Post by asveikau » Wed, Dec 04, 2019, 4:51 PM UTC

vlaaad wrote: 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.

The typical usage for StringBuilder tends to make it pretty obvious you're using a StringBuilder and everybody expects you will convert to a string at the end. Usually StringBuilders are short lived and all the calls and the declaration are close to each other.

Re: Never Use toString() for Behaviour

#27

Post by pavlov » Wed, Dec 04, 2019, 4:58 PM UTC

Java's eccentric uncle Objective-C called this method "description" instead of "toString". That was a better name IMO because it avoids the suggestion that it's some kind of canonical string representation.

Re: Never Use toString() for Behaviour

#28

Post by benmmurphy » Wed, Dec 04, 2019, 4:59 PM UTC

josefx wrote: post #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.githu…

for most implementations it would not be possible to use the location in memory because most java garbage collectors will move stuff around in memory. they could use the location initially and cache it afterwards but this would seem tricky to do without breaking the hash code contract.

Re: Never Use toString() for Behaviour

#29

Post by randomidiot666 » Wed, Dec 04, 2019, 5:13 PM UTC

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()

Great advice to be unemployable.

Re: Never Use toString() for Behaviour

#30

Post by EpicEng » Wed, Dec 04, 2019, 5:22 PM UTC

asveikau wrote: post #26

vlaaad wrote: 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.

The typical usage for StringBuilder tends to make it pretty obvious you're using a StringBuilder and everybody expects you will convert to a string at the end. Usually StringBuilders are short lived and all the calls and the declaration are close to each other.

Ok, but then the rule is not to use toString() for behavior unless it "makes sense" to do so, which is not a rule at all.