Ceylon - Partie 3 : Typage

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 :

1. Ceylon - Partie 1 : Présentation & installation
2. Ceylon - Partie 2 : Concepts de base

Bonne lecture !

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:

Citation:

---

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

---

Pour moi, la référence ou fonction fait partie d'une API si elle est exposée, donc tout a fait le contraire de ce qui est écrit.

Dans ce code:

Code:

---

1 2	class GeneriqueTypeOptionnel<PremierType=String>() {} GeneriqueTypeOptionnel generiqueTypeOptionnel = GeneriqueTypeOptionnel<String>();

---

Est-ce que GeneriqueTypeOptionnel tout seul est automatiquement remplacé par GeneriqueTypeOptionnel<String>? Si c'est le cas on ne peut pas faire:

Code:

---

GeneriqueTypeOptionnel generiqueTypeOptionnel = GeneriqueTypeOptionnel<BougliBougla>();

---

N'est-ce pas?

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

---

Que signifient + et * dans ces déclarations?

Code:

---

1 2	{Object+} liste {Noeud*} noeuds

---

J'ai remarqué des fautes d'orthographe dans l'article, par exemple "qu'elle est le type exact"...

Dans la section III-A, je suppose que variableUnion réfère à demoUnion déclaré au-dessus?

Citation:

---

Envoyé par bredelet

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?

---

Tant 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.

Citation:

---

Envoyé par bredelet

Pourquoi n'est-il pas possible d'étendre un type déclaré avec le mot-clef alias, il semble que ce serait utile?

---

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é.

Citation:

---

Envoyé par bredelet

Pour moi, la référence ou fonction fait partie d'une API si elle est exposée, donc tout a fait le contraire de ce qui est écrit.

---

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.

Citation:

---

Envoyé par bredelet

Si c'est le cas on ne peut pas faire:

Code:

---

GeneriqueTypeOptionnel generiqueTypeOptionnel = GeneriqueTypeOptionnel<BougliBougla>();

---

N'est-ce pas?

---

Effectivement cela n'est pas possible. Pour omettre le type paramétré, il faut que ce soit le type par défaut.

Citation:

---

Envoyé par bredelet

Il semble que "object" déclare un singleton, c'est bien ça?

---

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.

Citation:

---

Envoyé par bredelet

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:

---

Effectivement, le problème ce n'est pas qu'ils soient covariants ou contravariants mais qu'ils ne soient pas "invariants".

Citation:

---

Envoyé par bredelet

Que signifient + et * dans ces déclarations?

Code:

---

1 2	{Object+} liste {Noeud*} noeuds

---

---

Il s'agit de séquences. Elles seront abordées dans le chapitre "V. Collections".

Citation:

---

Envoyé par bredelet

Dans la section III-A, je suppose que variableUnion réfère à demoUnion déclaré au-dessus?

---

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.

Je te remercie pour ces remarques ! L'article a été mise à jour.