Modifications apportées à la bibliothèque standardNotez que toutes les nouvelles fonctions sont ajoutées à la bibliothèque standard à l'état expérimental.
Extension de StringBuilder dans la bibliothèque commune
StringBuilder était déjà présent dans la bibliothèque standard commune, dans le package kotlin.text. Cependant, de nombreux membres importants manquaient à l'appel ou n'étaient disponibles que sur la machine virtuelle Java. Désormais, toutes les fonctionnalités JVM de StringBuilder ont été ajoutées à la class expect commune avec les implémentations correspondantes sur différentes plateformes. Cela signifie que vous pouvez utiliser efficacement StringBuilder à partir du code commun car tous les membres nécessaires sont là.
Travailler avec KClass
Certains membres utiles de base de KClass ne nécessitent plus de dépendance kotlin-reflect sur la machine virtuelle Java:
| Code Kotlin : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 | import kotlin.reflect.cast @OptIn(ExperimentalStdlibApi::class) fun main() { val kClass = String::class println(kClass.simpleName) // String println(kClass.qualifiedName) // kotlin.String println(kClass.isInstance("abc")) // true println(kClass.isInstance(10)) // false println(kClass.cast("abc")) // abc } |
Renommage des annotations expérimentales (@Experimental et @UseExperimental)
Comme vous le savez peut-être, Kotlin a un mécanisme intégré pour utiliser des fonctionnalités expérimentales. Il comprend des annotations de la bibliothèque standard, qui marquent des déclarations qui sont soit expérimentales elles-mêmes, soit utilisent d'autres déclarations expérimentales. Dans les versions précédentes, il s'agissait de @UseExperimental et @Experimental.
JetBrains a décidé d'élargir le champ d'application de ce mécanisme, car un élément à l'état expérimental n'est pas la seule raison d'exiger le consentement pour utiliser des API. Par exemple, une API peut être interne ou avoir certaines restrictions. JetBrains a renommé les annotations pour refléter cela : les noms @OptIn et @RequiresOptIn ont remplacé @UseExperimental et @Experimental, en conséquence. L'argument du compilateur -Xuse-experimental a été renommé en -Xopt-in. Quant à -Xexperimental, il a été abandonné car il est rarement utilisé et augmente la complexité. Les anciennes déclarations @Experimental et @UseExperimental sont toujours prises en charge dans la version 1.3.70, mais seront supprimées dans la version 1.4.
Changement de nom de l'API expérimentale de mesure du temps
Un autre changement de nom que JetBrains a fait concerne l'API de mesure de la durée et de l'heure. Clock et ClockMark ont été renommés TimeSource et TimeMark en conséquence. Les noms précédents sont conservés en tant qu'alias de type obsolètes pour l'instant.
Implémentation de file d'attente à double extrémité: ArrayDeque
JetBrains a annoncé l'ajout de l'implémentation de la file d'attente double, la classe kotlin.collections.ArrayDeque, à la bibliothèque standard de Kotlin! La communauté le demande depuis un certain temps. Même si vous pouviez utiliser la classe java.util.ArrayDeque de la bibliothèque standard Java, il n'y avait aucune implémentation commune que vous pouviez utiliser pour Kotlin / JS, Kotlin / Native et, surtout, dans le code commun. Maintenant, une telle implémentation est disponible, bien qu'à l'état expérimental.
Une file d'attente à double extrémité vous permet d'ajouter / supprimer des éléments à la fois au début et à la fin de la file d'attente en temps constant amorti:
| Code Kotlin : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | @OptIn(ExperimentalStdlibApi::class) fun main() { val deque = ArrayDeque(listOf(1, 2, 3)) deque.addFirst(0) deque.addLast(4) println(deque) // [0, 1, 2, 3, 4] println(deque.first()) // 0 println(deque.last()) // 4 deque.removeFirst() deque.removeLast() println(deque) // [1, 2, 3] } |
Vous pouvez utiliser une file d'attente à double extrémité par défaut lorsque vous avez besoin d'une file d'attente ou d'une pile dans votre code.
L'implémentation kotlin.collections.ArrayDeque utilise un tableau redimensionnable en dessous: elle stocke le contenu dans un tampon circulaire, un tableau, et ne redimensionne ce tableau que lorsqu'il est plein.
Conceptuellement, l'implémentation d'ArrayDeque est très similaire à celle de java.util.ArrayDeque. Notez cependant qu'il s'agit d'une implémentation différente et que cette nouvelle implémentation sera utilisée lorsque vous utiliserez cette classe pour Kotlin / JVM. Cela diffère de la façon dont cela fonctionne avec d'autres collections: lorsque vous créez un ArrayList et le compilez sur JVM, la classe java.util.ArrayList est utilisée sous le capot. Contrairement à ArrayDeque de Java, qui implémente uniquement l'interface Collection, ArrayDeque de Kotlin implémente MutableList. Cela signifie que vous pouvez accéder à tous les éléments par index, ce qui n'est pas possible dans ArrayDeque de Java.
reduceOrNull() et randomOrNull()
Vous connaissez cette convention dans Kotlin : avoir une paire de fonctions, où la première lève une exception si l'opération n'est pas possible, et la seconde renvoie null, comme [C]string.toInt()[C] et string.toIntOrNull(). L'éditeur a ajouté de nouvelles fonctions homologues randomOrNull() et reductionOrNull(), suivant la même convention.
| Code Kotlin : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 | @OptIn(ExperimentalStdlibApi::class) fun main() { val list = listOf(1, 2, 3) println(list.randomOrNull()) // 2 println(list.reduceOrNull { a, b -> a + b }) // 6 val emptyList = emptyList<Int>() println(emptyList.randomOrNull()) // null println(emptyList.reduceOrNull { a, b -> a + b }) // null } |
Si vous utilisez random() ou reduce(), vous obtiendrez une exception si la collection est vide.
Les fonctions scan
Kotlin 1.3.70 s'accompagne d'un nouvel ensemble de fonctions pour travailler avec des listes et des séquences. Elles représentent le concept de « scanner »; des fonctions similaires sont déjà présentes dans différentes bibliothèques et langages.
scan() est étroitement lié à fold(). scan() et fold() appliquent à la fois l'opération binaire donnée à la séquence de valeurs, mais diffèrent en ce que scan() renvoie la séquence entière des résultats intermédiaires, tandis que fold() ne renvoie que le résultat final.
| Code Kotlin : | Sélectionner tout |
1 2 3 4 5 6 7 8 | @OptIn(ExperimentalStdlibApi::class) fun main() { val ints = (1..4).asSequence() println(ints.fold(0) { acc, elem -> acc + elem }) // 10 val sequence = ints.scan(0) { acc, elem -> acc + elem } println(sequence.toList()) // [0, 1, 3, 6, 10] } |
Prise en charge d'IntelliJ IDEA
Cette version inclut plusieurs améliorations pour la prise en charge de Kotlin dans IntelliJ IDEA. Passons en revue les plus intéressants.
Prise en charge de *.gradle.kts
En 1.3.70, JetBrains a travaillé pour améliorer la prise en charge d'IntelliJ IDEA pour les scripts Gradle Kotlin DSL (fichiers *.gradle.kts). En conséquence, la dernière version du plugin Kotlin présente de meilleures performances dans la mise en évidence de la syntaxe, la complétion, la recherche et d'autres aspects du travail avec les scripts de construction Kotlin.
Pour profiter de toutes les modifications et améliorations, assurez-vous d'utiliser IntelliJ IDEA 2019.2 ou version ultérieure avec Gradle 6.0 ou version ultérieure.
Complétion du code
Dans la version 1.3.70, JetBrains a apporté des améliorations notables à la complétion du code Kotlin dans IntelliJ IDEA. Désormais, les suggestions d'achèvement incluent les fonctions déclarées dans les objets, y compris les fonctions d'extension, les remplacements au niveau de l'objet et même les fonctions déclarées dans les objets imbriqués.
JetBrains a également amélioré le modèle d'apprentissage automatique qui trie la liste des complétions et maintenant, les options les plus pertinentes apparaissent en haut.
Nouveaux schémas de couleurs
Pour vous permettre de modifier l'apparence du code Kotlin dans l'éditeur à votre convenance, JetBrains a ajouté de nouveaux schémas de couleurs personnalisables. En particulier, vous pouvez désormais définir vos propres schémas de couleurs pour les appels de fonction de suspension et les déclarations de propriétés.
Améliorations du débogage
Dans les versions précédentes, le débogueur Kotlin/Native avait un type de point d'arrêt distinct, ce qui confond certains utilisateurs avec un choix peu clair comme «quel type de point d'arrêt dois-je utiliser ici?». Désormais, le type de point d'arrêt unique Kotlin Line Breakpoint fonctionne pour les cibles JVM et Native.
Tests Kotlin/JS et Kotlin/Native
Les résultats des tests pour Kotlin/JS et Kotlin/Native sont désormais affichés directement dans IntelliJ IDEA, comme cela a toujours été le cas pour les tests Kotlin/JVM. En outre, JetBrains a corrigé le filtrage des tests pour Kotlin/JS, de sorte que vous pouvez exécuter des tests individuels, et les tests Kotlin/Native ciblant le simulateur iOS peuvent enfin également être lancés directement en appuyant sur le bouton "Play".
Kotlin/JVM
Kotlin peut désormais générer des annotations de type dans le bytecode JVM (version cible 1.8+), afin qu'elles deviennent disponibles au moment de l'exécution. Cette fonctionnalité est demandée par la communauté depuis un certain temps, car elle facilite l'utilisation de certaines bibliothèques Java existantes et donne plus de pouvoir à ceux qui créent de nouvelles bibliothèques.
Dans l'exemple suivant, l'annotation @Foo sur le type String peut être émise vers le bytecode puis utilisée par le code de la bibliothèque:
| Code Kotlin : | Sélectionner tout |
1 2 3 4 5 6 | @Target(AnnotationTarget.TYPE) annotation class Foo class A { fun foo(): @Foo String = "OK" } |
Pour émettre l'annotation de type dans le bytecode, procédez comme suit:
[LIST][*]Assurez[/*]...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.