New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix dualkotlintest #1064
Fix dualkotlintest #1064
Conversation
This is a little optimization to save doing this reflective attempt before other types that can't be generated, like lists/arrays/maps/etc
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The code looks good, here, but I'm a little unclear about the use case. Why would someone choose to use the reflection adapter and have that override generated adapters? If you didn't want codegen wouldn't you just not include the kapt dependency?
If this is just for the test, I wonder if there's a way to either make the test more representative by breaking out the functional reflection test into it's own module that doesn't include codegen, or using some internal constant or something that the compiler can optimize away, so we don't add an if check and constructor param confusion, adding complexity to the code for a test case. |
Yeah it's kind of just for the test. Breaking out tests would be a lot of duplication. Maybe just a simple internal backdoor but there's no package private in Kotlin :/ |
I haven't found a good way to do this in Kotlin. Wish I had some idea to
help.
…On Mon, Jan 13, 2020 at 11:09 AM Zac Sweers ***@***.***> wrote:
Yeah it's kind of just for the test. Breaking out tests would be a lot of
duplication. Maybe just a simple internal backdoor but there's no package
private in Kotlin :/
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
<#1064?email_source=notifications&email_token=AAJ4S3WGUILH6XRTDGIP323Q5SN4FA5CNFSM4KFUIWBKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIZQMYQ#issuecomment-573769314>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAJ4S3UCIA53EHFH4AIX2RDQ5SN4FANCNFSM4KFUIWBA>
.
|
I've got another idea. Involves a backdoor but it's at least not public API |
This wasn't actually running reflection before because the reflection adapter will use generated adapters anyway if available. I've added an overload that allows controlling this behavior (default is enabled), as I'm not sure how else to set this up.
This also makes an opportunistic optimization to defer checking for generated classes until just before the ClassJsonAdapter, as it avoids unnecessary reflection checks before other non-generatable-types like collections/maps/arrays.