juin
2013
Un article de bredelet
En langage C, la déclaration d’un enum énumère une liste d’identifiants associés avec cet enum (d’où son nom) et affecte une valeur numérique unique pour chacun d’entre eux. En Java, l’idée est la même mais les identifiants appartiennent au namespace de l’Enum et les valeurs peuvent être non-numériques.
Exemple d’enum en C:
Le type enum de dodo est différent. En fait, il correspond au type des identifiants tels que « plan »; la différence est qu’il n’y a pas de liste d’identifiants définie. Donc dodo permet de faire:
Heureusement il y a moyen de définir quels enums peuvent être affectés à une variable.
Cela se fait à l’aide d’une variable d’ensemble ou de table associative. Par exemple:
Dans cet exemple, style est un ensemble qui a quatre éléments. Un élément de cet ensemble est de type style.member, qui de par la déclaration est un enum… Mais dodo s’assure que l’élément est bien listé dans l’ensemble!
On peut donc déclarer une variable comme un enum appartenant à l’ensemble « style »:
C’est un concept puissant qui peut s’appliquer à d’autres types qu’enum, par exemple si l’on veut limiter la valeur d’une chaîne de caractères à un ensemble de chaînes bien défini.
Pour associer une valeur numérique à chaque identifiant, il faut utiliser une table associative plutôt qu’un ensemble:
jours.label jour = mardi # ok, mardi est associé avec l'entier 2 dans la table
Un enum qui appartient à deux ensembles peut être utilisé pour les deux. Mais un type d’enum n’est compatible que si l’ensemble est inclus dans l’autre. On pourrait faire:
semaine.member m = jour.value # ok, l'ensemble de jours.label est inclus dans semaine
Dodo associe une valeur interne à chaque enum qu’il rencontre pour pouvoir comparer les enums entre eux. Mais deux programmes dodo n’utilisent pas la même valeur interne pour le même enum. Par exemple, « plan » dans un programme peut être associé avec la même valeur que « creux » dans l’autre. Cela pose problème si ces programmes veulent échanger des données.
Pour pallier à cela, dodo demande que les enums échangés fassent toujours partie d’un ensemble (on peut utiliser style.member mais pas directement enum), et les deux programmes s’échangent la position d’un élément dans l’ensemble plutôt que sa valeur interne. De cette façon « plan » reste « plan » et ne se transfome pas en « creux » quand il est envoyé par message.