im working on some additional assertions for `File...

# strikt

[mkobit]

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?

[robfletcher]

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.

[mkobit]

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

[robfletcher]

I think a not { startsWith(foo) } is a good idea and would make negation easier to manage