Skip to content

Updating reflect.lite to the new kotlinx.metadata.jvm #19

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

Merged
merged 74 commits into from
Aug 30, 2022

Conversation

mvicsokolova
Copy link
Contributor

No description provided.

* See the [Kotlin language documentation](https://kotlinlang.org/docs/reference/annotations.html)
* for more information.
*/
public interface KAnnotatedElement {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, since the end goal is to re-implement the interfaces from the reflect library, the approach is good.

@dkhalanskyjb
Copy link

Looking more closely, I don't think these interfaces are what we want. KClass, KCallable, etc., are all already present in the standard library. For example, just doing import kotlin.reflect.KCallable already gives access to KCallable, even inside this project. What we need is to reimplement this API: https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.reflect.full/ (https://github.com/JetBrains/kotlin/tree/master/core/reflection.jvm/src/kotlin/reflect/full)

@dkhalanskyjb
Copy link

On the second thought, the approach of having our own copies of the interfaces can also be good. The kotlin-reflect library assumes that only it implements the interfaces from the standard library and will give wrong answers if it's not the case. For example, https://github.com/JetBrains/kotlin/blob/1b49105c78c566ec42b422cbd46782b47a0d9f40/core/reflection.jvm/src/kotlin/reflect/jvm/ReflectJvmMapping.kt#L40.

So, maybe we should keep our own copies for now. Reverting to the ones from the standard library shouldn't be difficult if we want to later.

import kotlinx.reflect.lite.misc.*
import kotlinx.reflect.lite.name.*

object JavaToKotlinClassMap {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be internal, right? What do you think about enabling the API mode now so that there's no chance that objects like this will leak to the API?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, this is definitely internal. I'll add explicitApi check 👌🏻


val FQ_NAMES = FqNames()
class FqNames {
val array = FqName("kotlin.Array")

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I'll add the note

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please do, it will make reviewing the PR a lot easier. I'll easily see what is just a copy-paste of code that may be boilerplate-y is just used for its facilities, and what is the actual crux of the solution.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is more relevant than ever. I'm quite lost in the codebase now.

@qwwdfsad qwwdfsad self-requested a review August 30, 2022 17:19
Copy link
Member

@qwwdfsad qwwdfsad left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yay!

@mvicsokolova mvicsokolova merged commit 23297f1 into dev Aug 30, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants