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