Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Provide support for Kotlin extension methods on Subjects #536
The title might be a little off. We recently converted the Point of Sale Android codebase at Square from AssertJ to Truth and used Kotlin for our custom Subjects. I try to walk you through the issues I ran into, maybe it is beneficial for your future API considerations.
Kotlin supports extension function, what allows "extending" existing Subjects easily and in a fluent way. My goal was to extend the
assertThat("hello world").compressWhitespaces().isEqualTo("hello world")
From Java's point of view
The first problem I ran into is that
assertAbout(compressWhitespaces()).that("string string").isEqualTo("string string")
assertAbout(compressWhitespaces()).that("string string").isNotEqualTo("string string") // doesn't throw at the moment
To summarize those are the things I wish would be available or different.
Thanks very much for all the detail. I was intrigued when you mentioned using extension methods like this, so it's sad to hear that they don't quite work as is.
One initial question to buy me time to think about this more: In this particular case, how much does it help to put
(I'm wondering if this is going to lead us to create a separate
Copying some internal discussion and thoughts. I was actually writing some Kotlin Truth subjects just as this issue got posted, so I had a couple.
I think @cgruber is right that the linked issue, about reorganizing subjects, would help. Having isEqualTo on Subject definitely kind of bakes in an assumption that there's exactly one Subject per type, and they'll all e.g. have the same notion of equality.
I'd personally be hesitant to expose
To be clear, writing vanilla Subjects in Kotlin is quite doable and pleasant, and the ability to have top-level
I admit to some anxiety about relying on reflective access, but I can see why you're doing it. I would suggest that in the process, that reflective access actually be through a utility which has a consistent API, to avoid having subject implementers rolling their own reflection, and insulating internal changes a bit.