ctubbsii commented on pull request #2529: URL: https://github.com/apache/thrift/pull/2529#issuecomment-1066309086
> I would argument 4 is needed because in my use case both Java code and kotlin code will be consumers and Java needs option returning getters to do proper option chaining while having null returning getters makes kotlin recognize the property as is and it does option chaining from there. I'm not so sure it's needed, because if you didn't have option 4, then: 1. If you select the original nullable types, the option chaining works fine in Kotlin, but in Java, you'd just do: `var x = Optional.ofNullable(MyThriftType.getMyField())` 2. If you select the JDK8 option, then everything works nicely in Java, but in Kotlin, I think you could just do something like: `val x: SomeType? = MyThriftType.getMyField().orElse(null)` (or one of the [other examples here](https://stackoverflow.com/q/38767376/196405)) So, even if you didn't have option 4, you'd still have a choice between two relatively convenient options. So, I don't think having option 4 is particularly compelling, especially since it creates getters that do the same thing as option 3, but with a completely different name. Having both option 3 and option 4 is likely to be confusing, and over time, it's likely to incur technical debt, with very little benefit, other than to support users who are generating a library intended for use with both Kotlin and Java, which is a *very* niche use case. If I were using Kotlin (and I'm not), I would probably use the JDK8 option (option 3), and convert them to Kotlin nullables using [this suggestion](https://stackoverflow.com/a/38767769/196405). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
