Estoy aprendiendo Kotlin y yo estoy leyendo este día Kotlin en acción . Al leer el capítulo sobre funciones de extensión y mejora de la biblioteca estándar, leí acerca de un comportamiento diferente expuesto por String.splitsobrecargas entre Java y Kotlin: Creo que es una muy buena idea de avanzar hacia una separación explícita y más de tipo guiado entre los delimitadores y basados en expresiones regulares basadas en sobrecargas.
Sobre esto, el libro que he mencionado más arriba dice que Kotlin esconde el método confuso y proporciona como sustitutos de varias extensiones sobrecargadas nombradas splitque tienen diferentes argumentos .
Funciones de extensión responden a la questione "¿Cómo puedo añadir método a una clase existente"; por el contrario, no puedo imaginar cómo possibile ocultar 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"tieneks::class.qualifiedName == "kotlin.String"val ks = "Pietro Martinelli"tieneks::javaClass.name == "java.lang.String"- pasando el valor anterior
ksa un método Java, el parámetro recibidoxtienex.getClass().getName() == "java.lang.String"(como se esperaba) String js = "Pietro Martinelli"(en código Java) hajs.getClass().getName() == "java.lang.String", como se esperaba- pasando el anterior
jsvalor a un método Kotlin, el parámetro recibidoytieney::class.qualifiedName == "kotlin.String"yy.getClass().getName() == "java.lang.String"(como hasta el momento esperado)
Por lo tanto: parece que (permítanme decir) algo mágico ocurrió cuando utilizo Stringvalores en Kotlin y de ida y vuelta desde Kotlin a Java. Si undestand correctamente, Stringliterales en Kotlin son instancias de kotlin.Stringpero están limitados a un tipo Java que se utiliza de forma transparente para las llamadas de método Java. Esta biblioteca Kotlin manera puede mejorar Stringla experiencia sin afectar java.lang.String: Java habituales [java.lang.]String.splitmétodos están ocultos al código Kotlin en el sentido de que los desarrolladores Kotlin ver [kotlin.]Stringcasos y sus métodos.
Así, dos (relacionados) pregunta: 1. Es mi entendimiento correcto? Y, más interesante 2. es sólo una especie de poner la magia en su lugar por el compilador, que sabe String s como instancias de un especial tipo y las envuelve detrás instancias de una clase diferente, o hay algún enfoque más general / mecánico que permite de alguna manera ocultar algún método de una clase de la misma manera que podemos añadir métodos a través de la función de extensión mecánico? Puede ser muy peligroso, así que creo que es sólo cuestión de que el compilador , pero puede ser de gran alcance, también, así que creo que vale la pena la pregunta.
Gracias de antemano por consejos y evaluaciones.
Por desgracia, esto es magia compilador. Estos se llaman tipos mapeados , y el compilador les da un tratamiento especial para hacerlo de manera que sean visibles para el código Kotlin como los tipos Kotlin que han modificado las interfaces, a pesar de que en tiempo de ejecución que son instancias de los tipos regulares de Java cuando se compila a la JVM .
Aparte String, los ejemplos más notables son quizá las colecciones, que tienen dos capas de completamente nuevas interfaces aplican a ellos, a los de sólo lectura y mutables variantes.