(obviously with a better name than `f`)

# strikt

[robfletcher]

(obviously with a better name than f)

[christophsturm]

field?

[christophsturm]

you can already use chain{} inside the expect block, do you want a shorter name or what is the usecase?

[robfletcher]

yeah, I’m not sure. Something’s bothering me but I can’t quite put my finger on it

[christophsturm]

maybe we should really call it f{..}?

[christophsturm]

then you can really do

expect(foo) {
  f{it.bar}.isEqualTo("o hai")
  f{it.baz}.isEqualTo("kthxbye")
}

[christophsturm]

or remove the it syntax again, then you can write f{bar}

[robfletcher]

I’m wondering if it might even make sense to make the signature expectThat Assertion.Builder<T>.(T)->Unit

[christophsturm]

to make it nicer to read?

[robfletcher]

right

[christophsturm]

makes sense, but for map/chain i think its nicer without

[robfletcher]

I agree

[robfletcher]

I guess the name chain might be what I don’t like

[christophsturm]

yeah, map was nice, chain makes sense but is not so nice

[robfletcher]

it’s frustrating I couldn’t get both to be called map without creating multiple sub-interfaces which made declaring extension functions awkward

[christophsturm]

expect(foo) {
  f(bar).isEqualTo("o hai")
  f(baz).isEqualTo("kthxbye")
}

is also doable, but only with source code reading

[christophsturm]

the problem with source code reading is that its tied to the jvm

[robfletcher]

yeah

[christophsturm]

why not call it m for map, or f for field?

[robfletcher]

and only if you have access to the source code

[christophsturm]

but you have that usually when running the tests

[robfletcher]

yeah 99% of the time

[christophsturm]

i think field reads pretty good

expectThat(user) { field{lastName}.endsWith("owie") }