im working on some additional assertions for

File

and

Path

that im hoping to open an MR to

strikt

with, and seeing a few patterns emerge that im hoping to get some early feedback before working through it too much. 1. for certain "getter" style evaluation, is it better to expose as a property or function?

val <T : Path> Builder<T>.fileName: Builder<Path>

versus

fun <T : Path> Builder<T>.fileName(): Builder<Path>

2. for "boolean" style testing, like "is this readable", what is the desired API to expose?

val <T : Path> Builder<T>.isHidden: Builder<Boolean>

or

// assert(...)
fun <T : Path> Builder<T>.isHidden(): Builder<T>
fun <T : Path> Builder<T>.isNotHidden(): Builder<T>

(this gets a bit more complicated with checks like

exists

because the underlying API accepting varargs of

LinkOption

) 3. for assertion style things, is it best to offer multiple APIs for inversions and other possible for example:

fun <T : Path> Builder<T>.startsWith(other: String): Builder<T>
fun <T : Path> Builder<T>.doesNotStartWith(other: String): Builder<T>

or is there an opportunity to add something for consumers like an

doesNot { startsWith(other) }

to reduce API surface?

Sounds great. Quick answers on my phone, will follow up later: 1. I tend to follow the underlying API where appropriate (see the iterable stuff). 2. Where they accept options a method seems correct. 3. We do have a

not

method but it’s tricky because it inverts the entire chain downstream so I think having negated assertions can make sense where that would be a common use case.

thanks @robfletcher - hopefully ill have an MR up sometime this week

I think a

not { startsWith(foo) }

is a good idea and would make negation easier to manage