Pour essayer ces nouvelles fonctionnalit\u00e9s, vous devez sp\u00e9cifier la version 1.5 du langage<\/a> explicitement dans le code.<\/p>\n La nouvelle cadence de publication<\/a> implique que Kotlin 1.5 ne sera disponible que dans quelques mois, mais de nouvelles fonctionnalit\u00e9s sont d\u00e9j\u00e0 disponibles en avant-premi\u00e8re dans la version 1.4.30. Il est important pour nous de recevoir vos retours d’exp\u00e9rience au plus t\u00f4t, alors n’h\u00e9sitez pas \u00e0 essayer ces nouvelles fonctionnalit\u00e9s d\u00e8s maintenant !<\/p>\n <\/a><\/p>\n Les classes inline<\/a> sont disponibles en alpha<\/a> depuis Kotlin 1.3 et passent en b\u00eata<\/a>dans la version 1.4.30.<\/p>\n Kotlin 1.5 stabilise le concept de classes inline mais l\u2019int\u00e8gre \u00e0 une fonctionnalit\u00e9 plus g\u00e9n\u00e9rale, les classes de valeurs<\/em>, que nous d\u00e9crirons plus loin dans ce post.<\/p>\n Commen\u00e7ons par rappeler le fonctionnement des classes inline. Si vous connaissez d\u00e9j\u00e0 les classes inline, vous pouvez passer cette section et consulter directement les derni\u00e8res modifications<\/a>.<\/p>\n Pour rappel, une classe inline \u00e9limine une enveloppe (wrapper) autour d\u2019une valeur :<\/p>\n Une classe inline peut \u00eatre une enveloppe \u00e0 la fois pour un type primitif et pour tout type de r\u00e9f\u00e9rence, comme Le compilateur remplace les instances de classe inline (dans notre exemple, l\u2019instance En coulisse, le compilateur g\u00e9n\u00e8re la fonction Le nom est alt\u00e9r\u00e9 afin de permettre que la surcharge des fonctions prenant des instances de plusieurs classes inline se fasse de fa\u00e7on fluide et d’emp\u00eacher les appels accidentels du code Java qui pourraient violer les contraintes internes d\u2019une classe inline. Poursuivez votre lecture ci-dessous<\/a> pour savoir comment la rendre utilisable \u00e0 partir de Java.<\/p>\n L’enveloppe (wrapper) n\u2019est pas toujours \u00e9limin\u00e9e dans le bytecode. Cela n\u2019arrive que lorsque c\u2019est possible et fonctionne de mani\u00e8re tr\u00e8s similaire aux types primitifs int\u00e9gr\u00e9s. Lorsque vous d\u00e9finissez une variable du type Dans cet exemple, la variable En revanche, si vous la stockez dans une collection ou si vous la passez dans une fonction g\u00e9n\u00e9rique, elle est encapsul\u00e9e (boxing) dans un objet ordinaire du type La conversion boxing et unboxing est effectu\u00e9e automatiquement par le compilateur. Vous n\u2019avez rien \u00e0 faire, mais il est utile d’en comprendre le fonctionnement.<\/p>\n <\/a><\/p>\n \u00c0 partir de la version 1.4.30, vous pouvez changer le nom JVM d\u2019une fonction prenant une classe inline comme param\u00e8tre pour la rendre utilisable depuis Java. Par d\u00e9faut, ces noms sont modifi\u00e9s pour \u00e9viter les utilisations accidentelles de Java ou les surcharges conflictuelles (comme Si vous annotez une fonction avec Comme toujours avec une fonction annot\u00e9e avec \u00c0 partir de Java, vous pouvez envoyer directement une valeur En fournissant l\u2019annotation, vous soulignez<\/em> explicitement votre intention d\u2019appeler cette fonction depuis Java. Un nom descriptif permet d\u2019\u00e9viter toute confusion : l\u2019ajout du suffixe \u00ab\u00a0Millis\u00a0\u00bb au nom de la JVM rend les unit\u00e9s claires pour les utilisateurs de Java.<\/p>\n <\/a><\/p>\n Autre am\u00e9lioration pour les classes inline dans la version 1.4.30\u00a0: vous pouvez maintenant d\u00e9finir la logique d\u2019initialisation dans le bloc C’\u00e9tait interdit auparavant.<\/p>\n Vous pouvez en savoir plus sur les classes inline dans le KEEP<\/a> correspondant, dans la documentation<\/a> et dans la discussion de ce ticket<\/a>.<\/p>\n <\/a><\/p>\n Kotlin 1.5 stabilise le concept de classes inline et l\u2019int\u00e8gre \u00e0 une fonctionnalit\u00e9 plus g\u00e9n\u00e9rale : les classes de valeurs.<\/p>\n Jusqu\u2019\u00e0 pr\u00e9sent, les classes \u00ab\u00a0inline\u00a0\u00bb constituaient une fonctionnalit\u00e9 de langage distincte. Elles constituent maintenant une optimisation sp\u00e9cifique de la JVM pour une classe de valeur avec un seul param\u00e8tre. Les classes de valeurs repr\u00e9sentent un concept plus g\u00e9n\u00e9ral et prendront en charge plusieurs optimisations : les classes inline aujourd’hui et plus tard les classes primitives Valhalla lorsque le projet Valhalla sera disponible (voir ci-dessous<\/a> pour en savoir plus).<\/p>\n La seule chose qui change pour vous pour le moment est la syntaxe. \u00c9tant donn\u00e9 qu\u2019une classe inline est une classe de valeur optimis\u00e9e, vous devez la d\u00e9clarer diff\u00e9remment :<\/p>\n Vous d\u00e9finissez une classe de valeurs avec un param\u00e8tre de constructeur et l\u2019annotez avec <\/a><\/p>\n Une classe Dans les futures versions de Kotlin qui prendront en charge cette fonctionnalit\u00e9, il sera possible de d\u00e9finir des classes de valeurs avec plusieurs propri\u00e9t\u00e9s. Toutes les valeurs doivent \u00eatre des Les classes de valeurs n\u2019ont pas d\u2019identit\u00e9 : elles sont enti\u00e8rement d\u00e9finies par les donn\u00e9es stock\u00e9es et les contr\u00f4les d\u2019identit\u00e9 === ne sont pas autoris\u00e9s pour elles. Le contr\u00f4le d\u2019\u00e9galit\u00e9 == compare automatiquement les donn\u00e9es sous-jacentes.<\/p>\n Cette qualit\u00e9 \u00ab\u00a0sans identit\u00e9\u00a0\u00bb des classes de valeur permettra d\u2019importantes optimisations par la suite : l\u2019arriv\u00e9e du projet Valhalla dans la JVM permettra d\u2019impl\u00e9menter des classes de valeur en tant que classes primitives de la JVM en coulisse.<\/p>\n La contrainte d\u2019immuabilit\u00e9, et donc la possibilit\u00e9 d\u2019optimisations Valhalla, diff\u00e9rencie les classes <\/a><\/p>\n Le project Valhalla<\/a> introduit un nouveau concept dans Java et dans la JVM : les classes primitives.<\/p>\n L\u2019objectif principal des classes primitives est de combiner des primitives performantes avec les avantages orient\u00e9s objet des classes JVM ordinaires. Les classes primitives sont des conteneurs de donn\u00e9es dont les instances peuvent \u00eatre stock\u00e9es dans des variables, sur la pile de calcul, et exploit\u00e9es directement, sans en-t\u00eates ni pointeurs. \u00c0 cet \u00e9gard, elles sont similaires aux valeurs primitives comme Les classes primitives pr\u00e9sentent l’avantage notable de permettre la disposition plane et dense des objets en m\u00e9moire. Actuellement, Nous attendons avec impatience les changements \u00e0 venir dans la JVM et nous voulons que Kotlin en b\u00e9n\u00e9ficie. Pour autant, nous ne voulons pas forcer notre communaut\u00e9 \u00e0 d\u00e9pendre des nouvelles versions de la JVM pour utiliser <\/a><\/p>\n Il y a encore beaucoup \u00e0 dire sur la fonctionnalit\u00e9 de classes de valeurs. Comme les classes de valeurs repr\u00e9sentent des donn\u00e9es \u00ab\u00a0immuables\u00a0\u00bb, des m\u00e9thodes de mutation, comme celles de Swift<\/a>, sont possibles pour elles. Une m\u00e9thode de mutation est utilis\u00e9e lorsqu\u2019une fonction membre ou un setter de propri\u00e9t\u00e9 renvoie une nouvelle instance plut\u00f4t que de mettre \u00e0 jour une instance existante. Leur principal avantage est que vous les utilisez avec une syntaxe famili\u00e8re. Ce point doit encore \u00eatre prototyp\u00e9 dans le langage.<\/p>\n <\/a><\/p>\n L’annotation Vous pouvez en lire plus sur les classes de valeurs dans la Note de conception pour les classes Kotlin<\/a> ou regarder un extrait de l’intervention de Roman Elizarov \u00ab\u00a0A look into the future\u00a0\u00bb<\/a>.<\/p>\n <\/a><\/p>\n Autre am\u00e9lioration \u00e0 venir dans l\u2019\u00e9cosyst\u00e8me de la JVM\u00a0: les enregistrements Java<\/a>. Ils sont analogues aux classes Les enregistrements Java ne suivent pas la convention JavaBeans et ont des m\u00e9thodes \u00ab\u00a0x()\u00a0\u00bb et \u00ab\u00a0y()\u00a0\u00bb au lieu des m\u00e9thodes famili\u00e8res \u00ab\u00a0getX()\u00a0\u00bb et \u00ab\u00a0getY()\u00a0\u00bb.<\/p>\n L\u2019interop\u00e9rabilit\u00e9 avec Java a toujours \u00e9t\u00e9 et reste une priorit\u00e9 pour Kotlin. Ainsi, le code Kotlin \u00ab\u00a0comprend\u00a0\u00bb les nouveaux enregistrements Java et les consid\u00e8re comme des classes ayant des propri\u00e9t\u00e9s Kotlin. Cela fonctionne comme pour les classes Java normales suivant la convention JavaBeans :<\/p>\n Principalement pour des raisons d\u2019interop\u00e9rabilit\u00e9, vous pouvez annoter votre classe L\u2019annotation Cette annotation n\u2019est disponible que si vous compilez le code Kotlin vers une version 15+ de la JVM. Vous pouvez en savoir plus sur cette fonctionnalit\u00e9 dans le KEEP<\/a> correspondant, dans la documentation<\/a> et dans la discussion de ce ticket<\/a>.<\/p>\n <\/a><\/p>\n Lorsque vous d\u00e9clarez une classe sealed, cela restreint la hi\u00e9rarchie \u00e0 des sous-classes d\u00e9finies, ce qui permet des v\u00e9rifications exhaustives dans les branches Kotlin 1.5 supprime ces deux contraintes : vous pouvez d\u00e9sormais cr\u00e9er une interface<\/em> scell\u00e9e. Les sous-classes (tant pour les classes scell\u00e9es que pour les interfaces scell\u00e9es) doivent se trouver dans la m\u00eame unit\u00e9 de compilation et dans le m\u00eame paquet que la super classe, mais elles peuvent maintenant se trouver dans des fichiers diff\u00e9rents<\/em>.<\/p>\n Les classes scell\u00e9es, et maintenant les interfaces scell\u00e9es, sont utiles pour d\u00e9finir des hi\u00e9rarchies de types de donn\u00e9es abstraites (ADT).<\/p>\n Another important use case that can now be nicely addressed with sealed interfaces is closing an interface for inheritance and implementation outside the library. D\u00e9finir une interface comme sealed restreint son impl\u00e9mentation \u00e0 la m\u00eame unit\u00e9 de compilation et au m\u00eame paquet, ce qui, dans le cas d\u2019une biblioth\u00e8que, rend impossible son impl\u00e9mentation en dehors de la biblioth\u00e8que.<\/p>\n Par exemple, l\u2019interface En tant qu\u2019utilisateur de la biblioth\u00e8que, vous n\u2019\u00eates plus autoris\u00e9 \u00e0 d\u00e9finir votre propre sous-classe de <\/a><\/p>\n La prise en charge de l\u2019aper\u00e7u des classes scell\u00e9es a \u00e9t\u00e9 inaugur\u00e9e dans la version Java 15 et sur la JVM. \u00c0 l\u2019avenir, nous allons utiliser la prise en charge naturelle de la JVM pour les classes scell\u00e9es si vous compilez le code Kotlin avec la derni\u00e8re JVM (tr\u00e8s probablement la JVM 17 ou une version ult\u00e9rieure lorsque cette fonctionnalit\u00e9 sera stable).<\/p>\n En Java, vous listez explicitement toutes les sous-classes de la classe ou de l\u2019interface scell\u00e9e en question\u00a0:<\/p>\n Ces informations sont stock\u00e9es dans le fichier de la classe \u00e0 l\u2019aide du nouvel attribut \u00c0 l\u2019avenir, lorsque vous compilerez Kotlin sur la derni\u00e8re JVM, cette nouvelle prise en charge de JVM pour les classes scell\u00e9es sera utilis\u00e9e. En coulisse, le compilateur va g\u00e9n\u00e9rer une liste de sous-classes autoris\u00e9es dans le bytecode pour s\u2019assurer que la JVM est prise en charge et proc\u00e9der \u00e0 des v\u00e9rifications suppl\u00e9mentaires lors de l\u2019ex\u00e9cution.<\/p>\n En Kotlin, vous n\u2019avez pas besoin de sp\u00e9cifier la liste de sous-classes ! Le compilateur g\u00e9n\u00e9rera la liste en fonction des sous-classes d\u00e9clar\u00e9es dans le m\u00eame paquet.<\/p>\n La possibilit\u00e9 de sp\u00e9cifier explicitement les sous-classes pour une super classe ou une interface pourrait \u00eatre ajout\u00e9e ult\u00e9rieurement comme sp\u00e9cification optionnelle. Pour le moment, nous pensons que cela ne sera pas n\u00e9cessaire, mais nous attendons de conna\u00eetre vos cas d\u2019utilisation pour savoir si vous avez besoin de cette fonctionnalit\u00e9 !<\/p>\n Veuillez noter que pour les anciennes versions de la JVM, il est th\u00e9oriquement possible de d\u00e9finir une sous-classe Java pour l\u2019interface scell\u00e9e de Kotlin, mais ne le faites pas ! \u00c9tant donn\u00e9 que la prise en charge de la JVM pour les sous-classes autoris\u00e9es n\u2019est pas encore disponible, cette contrainte n\u2019est appliqu\u00e9e que par le compilateur Kotlin. Nous ajouterons des avertissements dans l’IDE pour \u00e9viter que cela ne se produise accidentellement. Par la suite, le nouveau m\u00e9canisme sera utilis\u00e9 pour les derni\u00e8res versions de la JVM afin de v\u00e9rifier l’absence de sous-classes \u00ab\u00a0non autoris\u00e9es\u00a0\u00bb de Java.<\/p>\n Vous pouvez en savoir plus sur les interfaces scell\u00e9es et les restrictions rel\u00e2ch\u00e9es des classes scell\u00e9es dans le KEEP<\/a> correspondant ou dans la documentation<\/a> et consulter la discussion dans ce ticket<\/a>.<\/p>\n <\/a><\/p>\n Vous devez utiliser Kotlin 1.4.30. Sp\u00e9cifiez la version<\/a> 1.5 du langage pour activer les nouvelles fonctionnalit\u00e9s :<\/p>\n Pour essayer les enregistrements JVM, vous devez en outre utiliser jvmTarget 15 et activer les fonctions d’aper\u00e7u de la JVM : ajoutez les options de compilation Notez que la prise en charge des nouvelles fonctionnalit\u00e9s est exp\u00e9rimentale et que la prise en charge de la version 1.5 du langage est en phase de pr\u00e9-publication. Param\u00e9trer la version du langage en 1.5 dans le compilateur Kotlin 1.4.30 \u00e9quivaut \u00e0 essayer la preview 1.5-M0. Les garanties de r\u00e9trocompatibilit\u00e9 ne couvrent pas les versions en pr\u00e9-publication. Les fonctionnalit\u00e9s et l\u2019API peuvent changer dans les versions ult\u00e9rieures. Lorsque nous arriverons \u00e0 la version finale Kotlin 1.5-RC, tous les binaires produits par les versions de pr\u00e9-publication seront interdits par le compilateur et vous devrez recompiler tout le code compil\u00e9 par 1.5-Mx.<\/p>\n Essayez les nouvelles fonctionnalit\u00e9s d\u00e9crites dans ce post et partagez vos retours avec nous ! Vous pouvez trouver plus de d\u00e9tails dans les KEEP, participer aux discussions dans YouTrack et nous signaler d’\u00e9ventuels incidents. Faites-nous part de vos observations sur l’efficacit\u00e9 des nouvelles fonctionnalit\u00e9s pour les cas d\u2019utilisation de vos projets !<\/p>\n Lectures et discussions compl\u00e9mentaires :<\/p>\n![\"\"](\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2021\/02\/Kotlin-1.4.30-new-lang-features-banner_2-02.png\")
<\/a><\/p>\nStabilisation des classes de valeurs inline<\/h2>\n
\ninline class Color(val rgb: Int)\n<\/pre>\n
String<\/code>.<\/p>\nColor<\/code>) par le type sous-jacent (Int<\/code>) dans le bytecode, lorsque c’est possible :<\/p>\n\nfun changeBackground(color: Color) \nval blue = Color(255)\nchangeBackground(blue)\n<\/pre>\n
changeBackground<\/code> avec un nom modifi\u00e9 prenant un param\u00e8tre Int<\/code> et envoie directement la constante 255<\/code> sans cr\u00e9er d’enveloppe au point de l\u2019appel :<\/p>\n\nfun changeBackground-euwHqFQ(color: Int) \nchangeBackground-euwHqFQ(255) \/\/ no extra object is allocated! \n<\/pre>\n
Color<\/code> ou que vous la passez directement dans une fonction, elle est remplac\u00e9e par la valeur sous-jacente :<\/p>\n\nval color = Color(0) \/\/ primitive\nchangeBackground(color) \/\/ primitive\n<\/pre>\n
color<\/code> a le type Color<\/code> lors de la compilation, mais elle est remplac\u00e9e par Int<\/code> dans le bytecode.<\/p>\nColor<\/code> :<\/p>\n\ngenericFunc(color) \/\/ boxed\nval list = listOf(color) \/\/ boxied\nval first = list.first() \/\/ unboxed back to primitive\n<\/pre>\n
Changement du nom de la JVM pour les appels Java<\/h3>\n
changeBackground-euwHqFQ<\/code> dans l\u2019exemple ci-dessus).<\/p>\n@JvmName<\/code>, cela change le nom de cette fonction dans le bytecode et permet de l\u2019appeler depuis Java et d’envoyer directement une valeur :<\/p>\n\n\/\/ d\u00e9clarations Kotlin\ninline class Timeout(val millis: Long)\n\nval Int.millis get() = Timeout(this.toLong())\nval Int.seconds get() = Timeout(this * 1000L)\n\n@JvmName("greetAfterTimeoutMillis")\nfun greetAfterTimeout(timeout: Timeout)\n\n\/\/ utilisation Kotlin\ngreetAfterTimeout(2.seconds)\n\n\/\/ utilisation Java\ngreetAfterTimeoutMillis(2000);\n<\/pre>\n@JvmName<\/code>, depuis Kotlin vous l\u2019appelez par son nom Kotlin. Kotlin offre un typage s\u00fbr car vous pouvez seulement envoyer une valeur de type Timeout<\/code> en tant qu’argument et les unit\u00e9s sont \u00e9videntes dans ce contexte.<\/p>\nlong<\/code>. Cela n’emp\u00eache plus les erreurs de types et c\u2019est pourquoi cela ne fonctionne pas par d\u00e9faut. Si vous voyez greetAfterTimeout(2)<\/code> dans le code, il n\u2019est pas imm\u00e9diatement \u00e9vident de savoir s\u2019il s\u2019agit de 2 secondes, 2 millisecondes ou 2 ans.<\/p>\nBlocs init<\/h3>\n
init<\/code> :<\/p>\n\ninline class Name(val s: String) {\n init {\n require(s.isNotEmpty())\n }\n}\n<\/pre>\nClasses de valeurs inline<\/h3>\n
\n@JvmInline\nvalue class Color(val rgb: Int)\n<\/pre>\n
@JvmInline<\/code>. Nous vous invitons tous \u00e0 utiliser cette nouvelle syntaxe \u00e0 partir de Kotlin 1.5. L\u2019ancienne syntaxe inline class<\/code> continuera \u00e0 fonctionner pendant un certain temps. Un avertissement dans la 1.5 vous informera de son abandon et comprendra une option de migration automatique de toutes vos d\u00e9clarations. Par la suite, elle sera obsol\u00e8te et renverra une erreur.<\/p>\nClasses de valeurs<\/h2>\n
value<\/code> repr\u00e9sente une entit\u00e9 immuable avec des donn\u00e9es. Actuellement, une classe value<\/code> ne peut contenir qu’une seule<\/em> propri\u00e9t\u00e9 pour prendre en charge le cas d\u2019utilisation des \u00ab\u00a0anciennes\u00a0\u00bb classes inline.<\/p>\nval<\/code> en lecture seule :<\/p>\n\nvalue class Point(val x: Int, val y: Int)\n<\/pre>\n
value<\/code> des classes data<\/code>.<\/p>\nFutures optimisations avec Valhalla<\/h3>\n
int<\/code>, long<\/code>, etc. (en Kotlin, on ne travaille pas directement avec les types primitifs mais le compilateur les g\u00e9n\u00e8re en coulisse).<\/p>\nArray<Point><\/code> est un tableau de r\u00e9f\u00e9rences. Avec la prise en charge de Valhalla, lorsque l\u2019on d\u00e9finit Point<\/code> comme une classe primitive (dans la terminologie Java) ou comme une classe de valeur avec l\u2019optimisation sous-jacente (dans la terminologie Kotlin), la JVM peut l\u2019optimiser et stocker un tableau de Point<\/code>s dans une disposition \u00ab\u00a0plane\u00a0\u00bb, directement sous la forme d’un tableau de plusieurs x<\/code> et y<\/code> plut\u00f4t qu’un tableau de r\u00e9f\u00e9rences.<\/p>\nles classes de valeurs<\/code>, nous allons donc les prendre en charge \u00e9galement pour les versions ant\u00e9rieures de la JVM. Lors de la compilation du code de la JVM avec le prise en charge de Valhalla, les derni\u00e8res optimisations de la JVM fonctionneront pour les classes de valeurs.<\/p>\nM\u00e9thodes de mutation<\/h3>\n
Plus d’informations<\/h3>\n
@JvmInline<\/code> est sp\u00e9cifique \u00e0 la JVM. Les classes de valeurs peuvent \u00eatre impl\u00e9ment\u00e9es diff\u00e9remment sur d’autres backends. Par exemple, sous forme de structs Swift dans Kotlin\/Native.<\/p>\nPrise en charge pour les enregistrements de la JVM<\/h2>\n
data<\/code> de Kotlin et sont principalement de simples conteneurs de donn\u00e9es.<\/p>\n\n\/\/ Java\nrecord Point(int x, int y) { }\n\/\/ Kotlin\nfun foo(point: Point) {\n point.x \/\/ seen as property\n point.x() \/\/ also works\n}\n<\/pre>\ndata<\/code> avec @JvmRecord<\/code> pour que de nouvelles m\u00e9thodes d\u2019enregistrement JVM soient g\u00e9n\u00e9r\u00e9es :<\/p>\n\n@JvmRecord\ndata class Point(val x: Int, val y: Int)\n<\/pre>\n
@JvmRecord<\/code> permet au compilateur de g\u00e9n\u00e9rer les m\u00e9thodes x()<\/code> et y()<\/code> au lieu des m\u00e9thodes standard getX()<\/code> et getY()<\/code>. Nous supposons qu\u2019il vous suffit d\u2019utiliser cette annotation pour pr\u00e9server l\u2019API de la classe lors de la conversion de Java en Kotlin. Dans tous les autres cas d\u2019utilisation, les classes data<\/code> famili\u00e8res de Kotlin peuvent s’utiliser \u00e0 la place sans probl\u00e8me.<\/p>\nAm\u00e9liorations des interfaces et des classes scell\u00e9es<\/h2>\n
when<\/code>. Dans Kotlin 1.4, la hi\u00e9rarchie des classes scell\u00e9es comporte deux contraintes. Premi\u00e8rement, la classe sup\u00e9rieure ne peut pas \u00eatre une interface scell\u00e9e, ce doit \u00eatre une classe. Deuxi\u00e8mement, toutes les sous-classes doivent se trouver dans le m\u00eame fichier.<\/p>\n\nsealed interface Expr\ndata class Const(val number: Double) : Expr\ndata class Sum(val e1: Expr, val e2: Expr) : Expr\nobject NotANumber : Expr\n\nfun eval(expr: Expr): Double = when(expr) {\n is Const -> expr.number\n is Sum -> eval(expr.e1) + eval(expr.e2)\n NotANumber -> Double.NaN\n}\n<\/pre>\nJob<\/code> du paquet kotlinx.coroutines<\/code> est uniquement destin\u00e9e \u00e0 \u00eatre impl\u00e9ment\u00e9e \u00e0 l\u2019int\u00e9rieur de la biblioth\u00e8que kotlinx.coroutines<\/code>. Le fait de la rendre sealed<\/code> rend cette intention explicite :<\/p>\n\npackage kotlinx.coroutines\nsealed interface Job { ... }\n<\/pre>\nJob<\/code>. Cela a toujours \u00e9t\u00e9 \u00ab\u00a0implicite\u00a0\u00bb, mais avec les interfaces scell\u00e9es, le compilateur peut formellement l\u2019interdire.<\/p>\nUtiliser la prise en charge de la JVM \u00e0 l\u2019avenir<\/h3>\n
\n\/\/ Java\npublic sealed interface Expression\n permits Const, Sum, NotANumber { ... }\n<\/pre>\nPermittedSubclasses<\/code>. La JVM reconna\u00eet les classes scell\u00e9es au moment de l\u2019ex\u00e9cution et emp\u00eache leur extension par sous-classes non autoris\u00e9es.<\/p>\n\n\/\/ pour la JVM 17 or later\nExpr::class.java.permittedSubclasses \/\/ [Const, Sum, NotANumber]\n<\/pre>\n
Comment essayer les nouvelles fonctionnalit\u00e9s<\/h2>\n
\ncompileKotlin {\n kotlinOptions {\n languageVersion = "1.5"\n apiVersion = "1.5"\n }\n}\n<\/pre>\n-language-version 1.5<\/code> et -Xjvm-enable-preview<\/code>.<\/p>\nNotes de pr\u00e9-version<\/h3>\n
Faites-nous part de vos commentaires<\/h3>\n
\n