Tout savoir sur le typage du langage Ceylon,
Un tutoriel de Logan Mauzaize
Le 2014-09-04 10:19:32, par Logan Mauzaize, Rédacteur/Modérateur
Bonjour à tous,
Je vous propose de poursuivre la découverte du langage Ceylon. Cette troisième partie présente l'un des points clés du langage, son système de typage : http://lmauzaize.developpez.com/tuto...ceylon/typage/
Toutes les remarques et suggestions sont naturellement les bienvenues.
Vous pouvez retrouver les articles précédents :
Bonne lecture !
Je vous propose de poursuivre la découverte du langage Ceylon. Cette troisième partie présente l'un des points clés du langage, son système de typage : http://lmauzaize.developpez.com/tuto...ceylon/typage/
Toutes les remarques et suggestions sont naturellement les bienvenues.
Vous pouvez retrouver les articles précédents :
Bonne lecture !
-
bredeletMembre éclairéPour l'exemple du switch (III-A), je suppose qu'il y a des problèmes de concurrence si la variable est déclarée shared? Mais dans la déclaration je ne vois pas shared. Peux-tu expliquer?
Pourquoi n'est-il pas possible d'étendre un type déclaré avec le mot-clef alias, il semble que ce serait utile?
Je n'ai pas compris ce passage:
L'inférence de type dans Ceylon consiste simplement à omettre le type, d'une référence ou de retour d'une fonction, si :
* celle-ci (la référence ou la fonction) n'est pas exposée, le langage suppose que cela fait alors partie d'une API
Dans ce code:Code : 1
2class GeneriqueTypeOptionnel<PremierType=String>() {} GeneriqueTypeOptionnel generiqueTypeOptionnel = GeneriqueTypeOptionnel<String>();
Code : GeneriqueTypeOptionnel generiqueTypeOptionnel = GeneriqueTypeOptionnel<BougliBougla>();
Il semble que "object" déclare un singleton, c'est bien ça?
Dans IV-C, il est dit que hériter de la même interface avec des paramètres génériques differents n'est possible que "si, et seulement si le type est covariant"
mais c'est suivi d'un exemple avec des types contravariants, j'ai du mal à suivre:Code : class ConsommateurAetB() satisfies ConsommateurA & ConsommateurB
Code : 1
2{Object+} liste {Noeud*} noeuds
Dans la section III-A, je suppose que variableUnion réfère à demoUnion déclaré au-dessus?le 17/09/2014 à 23:45 -
Logan MauzaizeRédacteur/ModérateurTant que la référence n'est pas variable il n'y a aucun soucis. Le fait qu'elle soit "shared" ou pas ne change rien dans ce cas.
Je ne suis pas le concepteur du langage, je ne pourrais donc pas répondre à cette question. Pose-la directement à Gavin King sur le forum.
Avec la sortie de la 1.1, il est possible que les choses aient évolué.
Effectivement c'est très mal dit. Ce que je voulais dire, c'est que si un élément est exposé, il fait alors partie d'une API et l'inférence sera interdite.
Effectivement cela n'est pas possible. Pour omettre le type paramétré, il faut que ce soit le type par défaut.
Effectivement, mais au delà du simple singleton, un "object" est aussi une définition de classe. Alors qu'un singleton en Java sera simplement une instance unique de la classe à laquelle il appartient. Les deux sont décorrélés.
Ce qui pose d'ailleurs des problèmes dans la gestion des énumérations dans la version 1.0 de Ceylon.
Effectivement, le problème ce n'est pas qu'ils soient covariants ou contravariants mais qu'ils ne soient pas "invariants".
Il s'agit de séquences. Elles seront abordées dans le chapitre "V. Collections".
Effectivement, il s'agit d'un problème dans le premier exemple (Voir le code source sous GitHub)
Encore merci pour toutes tes remarques, je ne manquerai pas de corriger l'articles dans les jours qui viennent.le 14/10/2014 à 14:28 -
Logan MauzaizeRédacteur/ModérateurJe te remercie pour ces remarques ! L'article a été mise à jour.le 16/10/2014 à 13:35