P
01/02/2024, 6:36 PMMatcherResult
, but I don't want to make it public (MatcherResult
to the same place where all the matcher results are, but then I'd have to add the :kotest-common
dependency (which contains the KotestInternal
annotation) to :kotest-assertions:kotest-assertions-api
(which contains all the default matcher results).
Or, I could just add the new MatcherResult
to the module I need (:kotest-assertions:kotest-assertions-shared
in my case) and mark the class as internal
.
Which option is more preferable for you?LeoColman
01/02/2024, 7:56 PMassertion library already looks like a dump, I wouldn't want to make it worseNo clue where this assumption comes from, the assertions library is part of core distribution What matcher do you want to add, and why do you think it shouldn't be public?
P
01/02/2024, 8:54 PMNo clue where this assumption comes from, the assertions library is part of core distributionKotest assertions can be used separately from kotest runtime, I don't know what you mean by that.
P
01/02/2024, 8:57 PMWhat matcher do you want to add, and why do you think it shouldn't be public?Oh, my bad, I wrote
Matcher
instead of MatcherResult
, fixed the original message.
I want to add a subclass of MatcherResult
(like ComparableMatcherResult
or EqualityMatcherResult
) and I don't want to make it public, because I want to be able to change the name, implementation, location, etc. of the class in the future without affecting compatibility.LeoColman
01/02/2024, 8:57 PMP
01/02/2024, 9:09 PMLeoColman
01/02/2024, 9:31 PMP
01/02/2024, 9:37 PM