robstoll / atrium-roadmap

Contains issues created by the maintainers of Atrium
1 stars 0 forks source link

allow `or` expressions but only for `filter`, `find` etc. #47

Closed robstoll closed 4 years ago

robstoll commented 5 years ago

Allowing or like constructs (with the exception of isAnyOf which is or-like) only in filter, find etc. means we need a way to track that. Same goes for a not expression in such contexts. If we want to control this during compile time, then we have to introduce quite of complexity and I guess assertion functions would then look more like:

fun <E, T : Iterable<E>, Z: Expect<T>> Exp.hasNext() : Z = ...

instead of

fun <E, T : Iterable<E>> Expect<T>.hasNext() = ...

The first version would certainly be too complex for a lot of people which means writing own assertion functions would be come too hard.

However, an or like structure will most likely pop up as feature request for filter, find etc. Thus: maybe we don't provide filter, find and the like as shortcut and one has to write it as

expect(listOf(1, 2, 3, 4, 8))
  .feature("it > 4 && it < 10 || it == 3") {s -> s.filter { it > 4 && it < 10 || it == 3 } }
  .containsExactly(3, 8)

which means one has to provide a description which fits on its own. We could still add filter as shortcut though as follows:

expect(listOf(1, 2, 3, 4, 8)).filter("it > 4 && it < 10 || it == 3") { it > 4 && it < 10 || it == 3 }

So that one at least does not have to write feature but honestly, I have never used filter in a test myself and I am not so sure if this is really something which deserves an own shortcut.

A compiler plugin might help here, one more use case next to #20

robstoll commented 4 years ago

let's drop this idea. If we really have the need for it then I guess a compiler plugin (#74 ) is the better choice