Make concurrency-friendly by adding a type that captures desired config options. Existing API fully preserved. #68
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Introduced
Differ
, a struct capturing all the config options (including the one passed as "flag"). It now hosts the implementation ofdeep.Equal
as the methodfunc(Differ)Compare
.Original
deep.Equal
preserved. Internally it delegates to a newDiffer
, which is configured from the package-level settings.Original tests have zero changes ensuring things work as expected.
I'm not confident the naming chosen is consistent / clear. Please help.
I've used
Compare
instead ofEqual
as method name onDiffer
because theEqual
is conventionally reserved forfun (Something) Equal(any) bool
signature.I've named the config struct
Differ
to convey the "thing that will calculate a diff" (even though it's just a wrapper for the config). PerhapsComparer
/Comparison
would sound better?The original Equal returned a
[]string
. I'm returning a named typeDelta
instead, to encapsulate implementation details and facilitate use/addition of common predicates (egdelta.IsEmpty()
,(Delta) Has(diff string) bool
, etc.)…But I read the Type Hiding anti-pattern on your blog. Would you (or the library users) prefer a plain
[]string
instead?