Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Kotlin class support #47
Nothing planned for now, I don't have much experience with Kotlin. That could change in a couple of months tho, so I'll keep this issue open.
I know Jake ported his ButterKnife to Kotlin, so it shouldn't be too hard. Pull requests or more info about what's required to make it work with Kotlin greatly appreciated.
Kotterknife, which is Jake's version of Butterknife view injection is not really a port and does not use annotation processing at all. He instead used Kotlin's property delegation support, which would not work well for Icepick.
The bottom line is that Kotlin does not support raw field access from one class to another. It has properties not fields from which it generates a private field and get/set methods.
What Icepick would need to do is add support for properties (using get/set methods) in addition to raw field access. That should be supported in 2 ways:
The first case above lets you do this:
where set and get could be customized such that there actually is no generated field. Future versions of Kotlin will allow this to be more concise.
The second case is the more basic:
which applies the Icicle annotation to the generated private field but generates get and set methods.
Note that adding property support would actually be useful in Java as well and would allow you to have get/seet for things you want to save that actually are computed without actually having backing fields.
Here are the relevant parts of Kotlin documentation:
There is also this: http://kotlinlang.org/docs/reference/java-interop.html, but the only relevant line is:
@dalewking Yes, handling only fields is not a deal-breaker when @State is used in conjuction with @JvmField (lateinit does a similar thing).
Nonetheless, as you say, it'd be nice to have setters and getters being handled properly by Icepick.
Thanks all for the useful information shared in this discussion.
If there is an effective workaround at the moment to get Icepick working with Kotlin I'd be inclined not to add complexity and change the codebase. Kotlin is a fast evolving language and adding explicit support for it makes me chase a moving target.
Happy to reconsider it in the future if the conditions change but closing it for now.