Reflect the annotations declared in constructor params #519
Conversation
Signed-off-by: shaishavgandhi05 <[email protected]>
Signed-off-by: shaishavgandhi05 <[email protected]>
There was a problem hiding this comment.
@shaishavgandhi05 thanks for this! Just one request - looks good besides that
| @@ -102,6 +103,11 @@ private fun JavaClassName.getSimpleNamesInKotlin(): List<String> { | |||
| return originalNames | |||
| } | |||
|
|
|||
| fun JavaAnnotationSpec.toKPoet(): KotlinAnnotationSpec { | |||
| val annotationClass = KotlinClassName.bestGuess(type.toString()) | |||
There was a problem hiding this comment.
This isn't quite right because it won't capture parameter values in the annotation - so it will only work for basic annotations.
If you're interested it would be great to add that full functionality, otherwise can you add a note warning of this partial implementation?
There was a problem hiding this comment.
Good catch. Will update the extension to include the parameter values also.
I'm interested in also adding tests for the PoetExtensions file. Would it be best for adding tests in the epoxy-processor module itself?
There was a problem hiding this comment.
@shaishavgandhi05 great! yes, I think adding tests to epoxy-processor makes sense
There was a problem hiding this comment.
After some investigation, this seems like something really hard to do. Parameters are added as CodeBlock's to the AnnotationSpec. There's no way to convert a JavaCodeBlock to KotlinCodeBlock since CodeBlock's have no getters to know what values they're going to emit.
Signed-off-by: shaishavgandhi05 <[email protected]>
|
Have updated the PR with a bunch of tests for PoetExtensions. Also, as noted in the comment before, some investigation revealed that it was hard to transfer parameters from |
There was a problem hiding this comment.
@shaishavgandhi05 hm, that param limitation is understandable so it seems fine to not support for now. Thank you for adding the comment and tests though.
I just have one last concern, I don't want code breaking if people do use annotations with values. For example, annotations like FloatRange are not that rare in android, and if generated code loses the parameters it won't compile.
Could we check which annotations have parameters and just omit those for now?
I can ship a new release as soon as this is merged :)
| import org.junit.Test | ||
| import javax.lang.model.element.Modifier | ||
|
|
||
| class PoetExtensionsTest { |
There was a problem hiding this comment.
Thanks a lot for the tests!
| @@ -102,6 +104,13 @@ private fun JavaClassName.getSimpleNamesInKotlin(): List<String> { | |||
| return originalNames | |||
| } | |||
|
|
|||
| // Does not support transferring complex annotations which | |||
| // have parameters and values associated with them. | |||
| fun JavaAnnotationSpec.toKPoet(): KotlinAnnotationSpec { | |||
There was a problem hiding this comment.
maybe this can be nullable, and we would return null if the JavaAnnotationSpec has a code block?
* Add test asserting null behavior Signed-off-by: shaishavgandhi05 <[email protected]>
|
Yup you're right. Don't want to break existing functionality. I've added a test for the null case as well as added it to the sample model so that we are sure it doesn't cause any compile errors. |
|
Excellent, thanks again! I'll try to push a new release asap |
|
No hurries. It's a nice to have, not a deal breaker 😄 |
If I declare a model like:
the Kotlin extension generated doesn't add the annotation to the extension function. However, it is added to the
AnnotationModel_class.This PR fixes that.