Johannes Link

@mpkorstanje What I had in mind is to treat function name handling in the existing platform module differently if the target class is a Kotlin class. This is indeed a...

If you want the perfect solution, a dependency on Kotlin is required because only Kotlin really knows how Kotlin names are being handled. The translation to bytecode methods is not...

> Could I try this one ? @jlink Sure. I was waiting for more input from the JUnit Team about which kind of solution they’d prefer. Apart from that I’m...

@fll02020 Give it a try. Maybe you can get hold of the Kotlin source to check what’s really happening with those special types UInt etc.

@fll02020 I'm afraid I don't know more than you do. My code is just handling the examples I stumbled upon by accident. I'd personally try to cover the cases that...

Just stumbled upon this article: https://ncorti.com/blog/name-mangling-in-kotlin The problem remains that the name mangling result for `internal` method can also be created by a back-ticked function name, e.g.: ```kotlin fun `looks...

> * We could introduce a `KotlinMethodSelector` variation on the `MethodSelector` and have API users use this when dealing with Kotlin (presumably they know). I'd advise against that. Having seen...

Actually, I don’t think the implementation would be too complicated. It’s just that I haven’t seen demand for it and I haven’t seen a good DSL/API suggestion for it, yet....

Sounds useful. The not-null should be easy to simulate: ```kotlin combine(ints(), ints()) { i, j -> if (i == j) { return null } Action { ... // call swap(i,...

> Adding `filter` to the combinators might be viable, however, it would require redeclaration of the variables which looks sad. That's true for all filter methods, right?