<@U3UQM2KV2> I think they should be just as discov...
# http4k
d
@tom_barnsbury I think they should be just as discoverable in the IDE - maybe I'm wrong? As for the extension vs member thing, it's a stylistic thing about what felt right when I wrote it. here's the code to explain a bit:
Copy code
interface Approver {
    fun <T : HttpMessage> assertApproved(httpMessage: T)
}

fun Approver.assertApproved(response: Response, expectedStatus: Status) =
    assertApproved(response.apply { assertEquals(expectedStatus, response.status) })

fun <T : HttpMessage> Approver.hasApprovedContent(): Matcher<T> = ...
The interface method is generified by HttpMessage, so for the first extension to be specific to
Response
felt a little wrong. The second was specific to hamkrest, which is totally outside the remit of the actual interface. On top of that, we don't even ship hamkrest with the module, so whilst convienient, it's even further away conceptually from the main interface.
t
Ah, fair enough, that makes sense actually. I found that I had to add the imports manually in order to use the extension functions, but it's highly likely I'm doing something wrong 🤷
d
@tom_barnsbury yep - they do appear (at least in IJ 2019.1)
t
Huh, I just checked again and they're offered to me without a manual import. So either my brain or my IDE were having a hiccup. Thanks for so graciously following me down that rabbit hole. 😑
😃 1