Repository navigation
Multiline-friendly toString() #730
Description
Activity
(Naturally this complicates the implementation....)
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?
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} }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 overridetoString()if there already is one.Yeah, this could be a
ToStringHelperfeature 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) thatToStringHelperis fairly rarely used now that AutoValue is around and that users usually wouldn't care enough to override AutoValue'stoString()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 thetoString()representations ahead of time).(
@ToPrettyStringhappened 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-linetoString()output, so I'm noting it here.)
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:
But you'd see:
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 AutoValuetoString()(like, to be fair, almost alltoString()implementations) makes it hard to see which field differs when there are a lot of fields. But of course one-linetoString()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.)