Hi folks. In my next PR, I want to add a new `Matc...
# kotest
p
Hi folks. In my next PR, I want to add a new
MatcherResult
, but I don't want to make it public (assertion library already looks like a garbage dump, I wouldn't want to make it worse). I could add the new
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?
l
assertion library already looks like a dump, I wouldn't want to make it worse
No 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
No clue where this assumption comes from, the assertions library is part of core distribution
Kotest assertions can be used separately from kotest runtime, I don't know what you mean by that.
What 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.
l
> Kotest assertions can be used separately from kotest runtime, I don't know what you mean by that. That assertions are part of the core kotest distribution, not a dump
p
> That assertions are part of the core kotest distribution, not a dump I meant literally "a garbage dump", not an IT term, sorry for the ambiguity 😅
l
And I meant literally not a garbage dump, it's maintained
p
ok, whatever