I'm learning Kotlin and I'm reading this days Kotlin in Action.
Reading the chapter about extension functions and standard library improvement, I read about different behaviour exposed by String.split
overloads between Java and Kotlin: I think it's a very good idea to move toward an explicit and more type-guided separation between delimiters-based and regex-based overloads.
About this, the book I've mentioned above says that Kotlin hides the confusing method and provides as replacements several overloaded extensions named split
that have different arguments.
Extension functions respond to the questione "How can I add method to an existing class"; on the other hand, I can't figure out how it's possibile to hide methods provided by the Java Standard Library.
I did some attempts writing simple code, and I noticed that
val ks = "Pietro Martinelli"
has ks::class.qualifiedName == "kotlin.String"
val ks = "Pietro Martinelli"
has ks::javaClass.name == "java.lang.String"
ks
to a Java method, the received parameter x
has x.getClass().getName() == "java.lang.String"
(as expected)String js = "Pietro Martinelli"
(in Java code) has js.getClass().getName() == "java.lang.String"
, as expectedjs
value to a Kotlin method, the received parameter y
has y::class.qualifiedName == "kotlin.String"
and y.getClass().getName() == "java.lang.String"
(as so far expected)So: it seems that (let me say) something magic occurred when I use String
values in Kotlin and back and forth from Kotlin to Java. If I undestand correctly, String
literals in Kotlin are instances of kotlin.String
but they are bounded to a Java type that is transparently used for Java method calls. This way Kotlin library can enhance String
experience without affecting java.lang.String
: usual Java [java.lang.]String.split
methods are hidden to Kotlin code in the sense that Kotlin developers see [kotlin.]String
instances and their methods.
So, two (related) question:
1. is my understanding right? And, more interesting
2. it's only a kind of magic put in place by the compiler, which knows String
s as instances of a special type and wraps them behind instances of a different class, or is there some more general approach/mechanic that permits to someway hide some method of a class the same way we can add methods through the extension function mechanic? It can be very dangerous, so I think it's only a matter of the compiler, but it can be powerful, too, so I think it's worth the question.
Thank in advance for hints and feedbacks.
If you want to hide visibility of the class instead of each functions or fields, you can use @file:JvmSynthetic on top of your class.
In Kotlin, public is a visibility modifier, and the open keyword is related to inheritance, which means they serve different purposes. In this tutorial, we'll see the difference between open and public keywords in detail.
Unfortunately, this is compiler magic. These are called mapped types, and the compiler gives them special treatment to make it so that they are visible to Kotlin code as the Kotlin types that have modified interfaces, even though at runtime they are instances of the regular Java types when compiled to the JVM.
Other than String
, the most notable examples perhaps are the collections, which have two layers of completely new interfaces applied to them, for the read-only and mutable variants.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With