Devoxx – Ceylon

Après avoir assisté à la session sur Kotlin, nous ne pouvions pas faire l’impasse sur la présentation du langage Ceylon animée par Emmanuel Bernard et Stéphane Epardaud. Cette session était focalisée sur les motivations qui ont poussé à développer ce langage et devait nous montrer les possibilités de ce dernier.

Le projet Ceylon a été initié par Gavin King dont nous connaissons tous la renommée. Emmanuel explique que pour des raisons de frustrations avec le langage Java, Gavin et son équipe ont décidé de monter ce projet. Ils souhaitent développer un langage avec l’esprit Java et étant aussi pratique que ce dernier.

Les buts du développement du langage Ceylon sont les suivants :

• facile à apprendre,
• moins verbeux tout en restant lisible,
• type safety améliorée,
• avoir un nouveau SDK (plateforme),
• possibilité de faire du meta-programming.

Emmanuel poursuit par du code, dont voici quelques exemples.

Les points qui changent par rapport à Java ou à d’autres langages de la JVM

La gestion de la visibilité

Toutes les classes, variables et méthodes sont par défaut avec une visibilité private. Seules deux visibilités existent : private (par défaut) et shared (public). Une classe privée n’est visible que par les autres classes du même module. Une méthode shared est visible par toutes les classes qui peuvent accéder à sa propre classe.

Surcharge

Par défaut, toutes les méthodes, attributs et classes ne peuvent pas être surchargés. À la place, Ceylon fournit dans sa syntaxe deux mots-clés permettant de gérer la surcharge de méthodes en plus du qualifieur par défaut.

• default : peut être surchargée. On définit l’implémentation par défaut.
• formal : doit être surchargée.
• actual : indique la surcharge. Plus ou moins équivalent à @Override en java.

abstract class Shape() {
 shared formal Natural area() ;

shared actual default String string {
  return "Abstract area : " area.string " m^2 ;
}

class Square(Natural width) extends Shape() {
  shared actual Natural area() {
    return width * width ;
  }
  shared actual String string = "Square area : " area.string " m^2" ;
}

Dans cet exemple, la méthode string est équivalente à toString en Java. Elle est surchargée dans Shape, elle doit donc être préfixée avec actual.

Overloading

Pas d’overloading que ce soit pour les méthodes standards ou le constructeur. Un seul constructeur est donc possible par classe. Mais il fournit en contrepartie des attributs optionnels. Emmanuel propose, pour le constructeur, d’utiliser un switch sur le type de l’argument.

void workWithRectange(Rectangle rect) { }
void workWithCircle(Circle rect) { }

void workWithFigure2D(Figure2D rect) { }

void supportsSubTyping(Shape fig) {
  switch(fig)
  case(is Rectangle) {
    workWithRectangle(fig) ;
  }
  case(is Circle) {
    workWithCircle(fig) ;
  }
  case(is Figure2D) {
    workWithFigure2D (fig) ;
  }
}

Rectangle, Circle et Figure2D sont ici des sous-classes de Shape.

Gestion du null

De la même manière que Kotlin, Ceylon utilise le caractère ‘?’ pour définir si une variable peut être nulle ou pas.

void typeSafety() {
  Cube? cubeOrNull() { return null; };
  Cube? Cube = cubeOrNull() ;

  print(cube.area.string) ;
}

Cet exemple génère une erreur de compilation. Il convient d’utiliser la forme ci-dessous.

void typeSafety() {
  Cube? cubeOrNull() { return null; };
  Cube? Cube = cubeOrNull() ;

  if (exists cube) {
    print(cube.area.string) ;
  } else {
    print("No cube") ;
  }
}

Union type

class Apple() {
  shared void eat() {}
}

class Snail() {
  shared void throwAway() {}
}

void unions() {
  Sequence<Apple|Snail> plate = {Apple(), Snail()};
  for (Apple|Snail food in plate) {
    print(food.string);
    if (is Apple food) {
      food.eat();
    } else if (is Snail food) {
      feed.throwAway();
    }
  }
}

L’union de types permet d’être sûr d’avoir un objet de type Apple ou Snail. Le mot-clé is permet de vérifier le type.

Autres fonctionnalités

Dans les autres fonctionnalités et syntaxes plus classiques, on retrouve :

• les closures,
• les annotations,
• un système d’interceptor pour la programmation par aspect,
• un système de modules.

Concernant l’outillage, Stéphane nous montre du code en live avec le plugin Eclipse. Ce dernier est assez avancé et nous retrouvons la coloration syntaxique, le refactoring, le type checking ainsi que le debugger.

Conclusion

Emmanuel termine la présentation en nous annonçant la mise en ligne du site sur Ceylon. N’hésitez pas à le consulter : la documentation est bien fournie (fonctionnement du langage, spécifications, etc…) et les exemples sont nombreux.

Enfin il ajoute que tout le monde est bienvenu sur le projet. Un github est disponible et il est possible de contribuer au projet dès à présent.

La séance s’est terminée par des questions/réponses. Nous avons notamment eu la question suivante : « Où se situe Ceylon par rapport à Kotlin ou à d’autres langages (Scala, Fantom) ? » Emmanuel explique que Ceylon se trouve entre le monde Kotlin et Fantom. Il justifie cela par le fait que le langage Fantom a pris le parti de supprimer certaines notions du langage Java et que dans Kotlin on ne retrouve pas la notion d’Union type.

À travers cette conférence, nous constatons que les nouveaux langages sont à la « mode ». Ceylon tente de se faire un chemin dans la bataille aux « successeurs de Java » avec d’autres challengers comme Kotlin. Il ne nous reste plus qu’à surveiller les évolutions de ces différents langages et de voir lequel proposera les meilleures approches de programmation dans les mois à venir.