Multiline-friendly toString()

[cpovirk]

One of the things we did in Truth a while back was to print values differently if they contain newlines. So, for example, you would see:

expected: foo
but was : bar

But you'd see:

expected:
    public class Foo {
      Foo() {}
    }
but was:
    public class Bar {
      Bar() {}
    }

I would speculate (but it's just speculation) that this might be a nice feature for AutoValue toString() implementations, too.

(Even in the case in which fields aren't multiline, a multiline toString() can be nice in some cases: I think Truth has gotten reports that AutoValue toString() (like, to be fair, almost all toString() implementations) makes it hard to see which field differs when there are a lot of fields. But of course one-line toString() is nice in plenty of cases, too, so I wouldn't advocate for always going multiline (nor, probably, for making it configurable). It's just a nice additional advantage in the cases in which multiline is already justified.)

(It's also possible that Truth should have more special handling of AutoValue types in some cases.)

[cpovirk]

(Naturally this complicates the implementation....)

[eamonnmcmanus]

I'm not finding this very clear. Could you give an example of what AutoValue does now and what you would like it to do?

[cpovirk]

Sorry about that.

Here's an example toString() from the tests:

Simple{publicString=example, protectedInt=23, packageMap={twenty-three=23}}

If a value has a newline, we end up with something like:

Simple{publicString=Here's another example.
It contains multiple lines., protectedInt=23, packageMap={twenty-three=23}}

In the later case, I'm proposing something more like:

Simple{
  publicString:
    Here's another example.
    It contains multiple lines.
  protectedInt:
    23
  packageMap:
    {twenty-three=23}
}

[eamonnmcmanus]

Thanks for the clarification!

We've always made AutoValue-generated code standalone, but this sounds as if it would require a support library. Especially if we do things properly, for example indenting further if there is a nested AutoValue object that also has newlines. Perhaps we could instead have a library somewhere, maybe even in Guava, that people could use in an explicit toString()? Of course AutoValue won't override toString() if there already is one.

[cpovirk]

Yeah, this could be a ToStringHelper feature request (though we sorta kinda commit to a format in its docs, so maybe this would have to be opt-in). That said, I suspect (without doing any research) that ToStringHelper is fairly rarely used now that AutoValue is around and that users usually wouldn't care enough to override AutoValue's toString() if it meant listing all their fields again (which might go out of date).

I don't think the code required for this is too complex -- roughly this (though that assumes that we've computed -- and perhaps stored in a List -- all the toString() representations ahead of time).

[cpovirk]

(@ToPrettyString happened at some point. That isn't the sort of automatic formatting change that I was thinking about, but it's a way of improving upon long, single-line toString() output, so I'm noting it here.)