Estoy aprendiendo Kotlin y estoy leyendo este día Kotlin en acción . Leyendo el capítulo sobre las funciones de extensión y la mejora de la biblioteca estándar, leí sobre los diferentes comportamientos expuestos por las sobrecargas de String.split entre Java y Kotlin: creo que es una muy buena idea avanzar hacia una separación explícita y más guiada por tipos entre delimitadores y sobrecargas basadas en expresiones regulares.
Sobre esto, el libro que mencioné anteriormente dice que Kotlin oculta el método confuso y proporciona como reemplazo varias extensiones sobrecargadas llamadas split que tienen diferentes argumentos .
Las funciones de extensión responden a la pregunta "¿Cómo puedo agregar un método a una clase existente?"; por otro lado, no puedo entender cómo es posible ocultar los métodos proporcionados por la Biblioteca estándar de Java .
Hice algunos intentos de escribir código simple y me di cuenta de que
val ks = "Pietro Martinelli" tiene ks::class.qualifiedName == "kotlin.String"val ks = "Pietro Martinelli" tiene ks::javaClass.name == "java.lang.String"ks a un método Java, el parámetro recibido x tiene x.getClass().getName() == "java.lang.String" (como se esperaba)String js = "Pietro Martinelli" (en código Java) tiene js.getClass().getName() == "java.lang.String" , como se esperabajs anterior a un método Kotlin, el parámetro recibido y tiene y::class.qualifiedName == "kotlin.String" e y.getClass().getName() == "java.lang.String" (como tal muy esperado) Entonces: parece que (permítanme decir) algo mágico ocurrió cuando uso valores de String en Kotlin y de Kotlin a Java. Si entiendo correctamente, los literales de String en Kotlin son instancias de kotlin.String pero están limitados a un tipo de Java que se usa de forma transparente para las llamadas a métodos de Java. De esta manera, la biblioteca de Kotlin puede mejorar la experiencia String sin afectar java.lang.String : los métodos habituales de Java [java.lang.]String.split están ocultos para el código de Kotlin en el sentido de que los desarrolladores de Kotlin ven [kotlin.]String y sus métodos.
Entonces, dos preguntas (relacionadas): 1. ¿Es correcto mi entendimiento? Y, más interesante 2. es solo un tipo de magia puesta en marcha por el compilador, que reconoce String s como instancias de un tipo especial y las envuelve detrás de instancias de una clase diferente, o hay algún enfoque/mecánica más general que permite para ocultar de alguna manera algún método de una clase de la misma manera que podemos agregar métodos a través de la mecánica de la función de extensión? Puede ser muy peligroso, por lo que creo que es solo una cuestión del compilador , pero también puede ser poderoso, por lo que creo que vale la pena la pregunta.
Gracias de antemano por las sugerencias y comentarios.
Desafortunadamente, esta es la magia del compilador. Estos se denominan tipos mapeados y el compilador les otorga un tratamiento especial para que sean visibles para el código de Kotlin como los tipos de Kotlin que tienen interfaces modificadas, aunque en tiempo de ejecución son instancias de los tipos de Java normales cuando se compilan en la JVM. .
Aparte de String , los ejemplos más notables quizás sean las colecciones, a las que se les han aplicado dos capas de interfaces completamente nuevas, para las variantes de solo lectura y mutables.