Coming from Java, what I have in mind when I think about reflection are highly dynamic non type-safe code like myClass.call("myMethodName", arg1, arg2)
But method reference seems to be a static thing: they are known at compile-time and type-safe, so I don’t understand why it is related to reflection.
I am asking that because reflection has a strong negative connotation related to performance and type-safety but obviously this “penalty” does not apply to method reference the same way it apply to other usage of reflection like the one above.
So why method reference in Kotlin is considered to be reflection?
It is not necessarily considered reflection. For example, I do not consider the usage of such things reflections. At least not runtime reflection, common for the Java ecosystem. It is a part of the reflection package and is using language’s own structure, that’s all.
The documentation is confusing then, because it says:
Reflection is a set of language and library features that allows you to introspect the structure of your program at runtime. (emphasis added)
And
On the JVM platform, the Kotlin compiler distribution includes the runtime component required for using the reflection features as a separate artifact, kotlin-reflect.jar .
And just after there is a section dedicated to method references.
Actually I just tested the “Function compositions” example mentioned in the documentation without loading the reflection library and it works.
I will raise a Youtrack issue to clarify the documentation
In Kotlin the reflection API is split into two parts:
“basic” reflection (I don’t know its actual name, if it has any) - basic stuff under kotlin.reflect package, built into stdlib.
kotlin.reflect.full - provided as separate kotlin-reflect library.
I agree, the documentation is imprecise a bit on that matter.
And speaking about reflection in general, It is sometimes hard to make a distinction on what is the reflection and what is not. Especially in languages where we can for example pass functions as first-class citizens. We can access names of functions, their parameters, so it sounds like the reflection, but on other hand that would mean half of the JavaScript code would be using the reflection.
We can separate runtime reflection, which is usually the weapon of the last resort, and other types of reflection, which are quite fine in the kotlin ecosystem. For example, the idiomatic when-is pattern could be considered reflection because it uses type-markers, not available in C++ for example.
