Thread
#strikt
    m

    mkobit

    3 years ago
    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

    robfletcher

    3 years ago
    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.
    m

    mkobit

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

    robfletcher

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