-
Notifications
You must be signed in to change notification settings - Fork 209
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
refactor: expose the DefaultReporter #226
Conversation
I am trying to stop go-cmp from calling fmt.Stringer, as this in some cases makes the output worse instead of better. The DefaultReporter implementation is quite customizable, but this functionality is not exposed to the user. While users can register custom exporters, they would then need to re-implement the entire DefaultExporter, even though changing a single bool in it's config would suffice. This PR exposes the DefaultReporter implementation so it can be customized and used outside of this package
The philosophical position of this project is to give as little knobs as possible to tweak the output. If the output is subpar (e.g., calling String is unhelpful), it is better to understand why and adjust the heuristics in the reporter to do a better job. Can you provide some examples where the String method has worse output than otherwise? |
Sure! I have a type that uses Because this is called, the diff now contains yaml squished to a single line, where I can't really see what's going on:
With regular Go-style printing however, this would be perfectly usable:
|
Thanks for the example, can you also show what it would look like if it had used the regular Go-style printing (for comparison)? |
Sure, sorry for that. Update above comment! |
Thanks for the examples. I'm inclined to say that we should adjust the reporter to print multiline String output as multiline output (rather than a quoted string) if this is this for a added, removed, or modified element (i.e., we continue to use quoted string if the element is equal). As a straw-man proposal, it might look something like:
|
For this specific case, that would indeed solve the problem in an elegant way 👍 In the general picture, I'd be a bit concerned about the Stringer use, because if I messed up my Stringer implementation to swallow data (ie. I could just omit a struct field), |
Can you file an issue for this? Alternatively, you're welcome to try implementing this yourself. The logic for triple-quoted strings in a diff is here, you may need to refactor parts of it out so that you can share similar functionality from the logic to print the stringer.
The reporter has logic to continually printing with more verbosity if the printed output is identical between the added and removed element. Thus, if the String method left out information that was the semantic reason for a difference, the reporter should eventually figure out that the String method alone doesn't provide that information and fall back to formatting the values as pseudo-Go objects. As much as possible, we'd like to push any notion of knobs for the reporter to be reasonable heuristics in the reporter such that it does a decent job a majority of the time, so that users don't need to play the game of guessing the best set of reporter knobs to format the diff output. |
#229 formats multiline strings within inequal nodes using the triple-quote syntax. |
That's so cool! Imo that's sufficient, we can close this once merged :) |
Closing in favor of #229 |
I am trying to stop go-cmp from calling fmt.Stringer, as this in some
cases makes the output worse instead of better.
The DefaultReporter implementation is quite customizable, but this
functionality is not exposed to the user.
While users can register custom exporters, they would then need to
re-implement the entire DefaultExporter, even though changing a single
bool in it's config would suffice.
This PR exposes the DefaultReporter implementation so it can be
customized and used outside of this package