Feature/3165 recursive comparison assert #3179
Open
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.
Check List:
Add
RecursiveComparisonAssert.withEqualsForTypes
andRecursiveComparisonAssert.withComparatorForTypes
methods to compare different type objects in a type-safe way. For the latter, I've added a BiComparator functional interface to avoid the declaration of aComparator<Object>
that requires a forced cast of the instances to be compared.Furthermore, to fix the type clash generated by this kind of registration
I've modified the internal TypeHolder data structure from
protected final Map<Class<?>, T> typeHolder;
to
protected final Map<Pair<Class<?>, Class<?>>, T> typeHolder;
This allows us to associate a Comparator to a type's pair ([String, LocalTime] -> comparator1).
Retro compatibility is maintained; in the following scenario
The typeHolder will contain this entry ([String, null] -> comparator1).
The only method that has changed the signature is
TypeHolder.entityByTypes
frompublic Stream<Entry<Class<?>, T> entityByTypes()
to
public Stream<Entry<Pair<Class<?>, Class<?>>, T>> entityByTypes()
that's why this cannot be considered as a safe change...let's talk about this