anchor.diff:  IDE. Tous ces produits sont codés en Java. Les développeurs de Jetbrains
   en sont à la conclusion que leur code pouvait être grandement simplifié
   : l'idée de Kotlin est donc né. L'équipe a fixé entr'autres les
  -objectifs suivants : +
  - +
  +objectifs suivants :
  +
   
   * Kotlin doit être compatible avec Java
   * le code Kotlin doit compiler au moins aussi vite que le code actuel
  -* le langage doit rester concis et simple (comprendre aussi par là :
  -plus concis que Java, plus simple que Scala)
  +* le langage doit rester concis et simple (comprendre aussi par là : plus concis que Java, plus simple que Scala)
   
   Les objectifs sont somme toute très similaires côté Red Hat, avec le
   projet Ceylon, dont http://www.ceylon-lang.org/[le site officiel] a été
   lancé le 18 novembre dernier, jour même de la conférence de présentation
  -par Emmanuel Bernard et Stéphane Epardaud. +
  - +
  +par Emmanuel Bernard et Stéphane Epardaud. 
   
   Types Nullable
   ++++++++++++++
   
   Parmi les points communs, on recensera les types __Nullable__. En effet,
   que ce soit en Ceylon : +
  - +
  -`String myString = null` +
  - +
  -ou en Kotlin : +
  - +
  -`var myString: String = null` +
  - +
  +
  +[source,ceylon]
  +----
  +String myString = null
  +----
  +
  +ou en Kotlin :
  +
  +[source,kotlin]
  +---- 
  +var myString: String = null
  +----
  + 
   ces deux exemples de code ne compileront pas. La valeur `null` n'existe
   que pour un seul type (`Nothing` en Ceylon). Pour y remédier, il
   "suffit" de modifier le type déclaré à `String?` (équivalent à
   `String|Nothing` en Ceylon - ici un type union : `String` OU
   `Nothing`). +
  - +
  +
  +
   Encore plus fort, les deux compilateurs sont assez intelligents pour
   affiner le type d'une variable selon les tests qui ont été effectués en
   préalable. Un premier exemple avec Ceylon : +
  - +
  -`void doSomething(String? arg) {   //print (arg.length); // wouldn't compile as arg could be null, the expression could throw an NPE   if (exists arg) {       print (arg.length); // compiles given arg cannot be null after this test   }}` +
  - +
  -À la ligne 4 de l'exemple ci-dessus, `arg` n'est plus de type
  -`String|Nothing` mais bien de type `String` seulement. +
  -Plus concisément (en Kotlin cette fois-ci): +
  - +
  -`print(myString?.length())` +
  - +
  +
  +[source,ceylon]
  +----
  +void doSomething(String? arg) {   
  +	//print (arg.length); // doesn't compile, the expression could throw an NPE   
  +	if (exists arg) {
  +    	print (arg.length); // compiles given arg cannot be null after this test   
  +	}
  +}
  +----
  +
  +À la ligne 4 de l'exemple ci-dessus, `arg` n'est plus de type `String|Nothing` mais bien de type `String` seulement. Plus concisément (en Kotlin cette fois-ci):
  +
  +[source,kotlin]
  +----
  +print(myString?.length())
  +----
  +
   Ici, si `myString` est `null`, alors l'expression sera directement
   évaluée comme étant `null`, sinon l'expression `myString.length` sera
   évaluée. Notez que cette syntaxe se retrouve aussi en Fantom. +
    +
   Pour résumer : une défaite pour les NPE, une victoire pour les amoureux
  -de Mark Question. +
  +de Question Mark. +
    +
   
   Classes et héritage
   +++++++++++++++++++
   
   Une classe en Kotlin ou en Ceylon définit à la fois un type mais aussi
  -un constructeur. En Ceylon : +
  - +
  -`shared class Counter(Natural initialValue=0) {    value count = initialValue;}` +
  - +
  +un constructeur. En Ceylon :
  +
  +[source,ceylon]
  +----
  +shared class Counter(Natural initialValue=0) {
  +	value count = initialValue;
  +}
  +----
  +
   Comme vous vous en doutez, `shared` en Ceylon s'apparente à `public` en
   Java. Pour être précis, Ceylon n'a que deux niveaux de visibilités. La
   classe `Counter` définit un constructeur qui prend un argument de type
  
positive.code: Mais qui dit héritage multiple dit "__how the f*ck are you gonna handle
  the http://en.wikipedia.org/wiki/Diamond_problem[Diamond Problem]?__"
  (exemple repris de la
  http://confluence.jetbrains.net/display/Kotlin/Classes+and+Inheritance[doc
  officielle] de Kotlin) : +
   +
  `open class A(virtual var v : int) open class B(v : Int) : A(v) open class C(v : Int) : A(v) class D(v : Int) : B(v), C(v) fun main(args : Array<String>) {     val d = D(10)     d.v = 5     print(d.v) }` +
   +
  Ici, le compilateur se plaindra du fait qu'il ne peut déterminer de quel
  _getter_ hérite le _getter_ implicite de la propriété `v` dans D. Afin
  de résoudre le problème, il est nécessaire de redéfinir la propriété `v`
  explicitement dans D de la façon suivante : +
   +
  `class D(v : Int) : B(v), C(v) {     override var v : Int     get() = super<B>.v     set(value) { super<B>.v = value } }` +
   +
  Par corollaire, le _setter_ de D pourrait hériter du _setter_ de B et le
  _getter_ de celui de C (ça va donner lieu à des _Kotlin puzzlers_ bien
  sympa, je le sens). +
   +
  
  Alors, Kotlin ou Ceylon ?
  +++++++++++++++++++++++++
  
  Sachez que je suis loin d'avoir couvert les possibilités offertes par
  ces deux langages : jetez un oeil aux documentations officielles par
  vous-mêmes. +
  Ce qui m'a plu chez Kotlin est le support multi-IDE (Eclipse, IntelliJ)
  et la réutilisation maximale des mots clefs Java. +
   +
  Côté Ceylon, j'ai particulièrement apprécié le côté ouvert du projet,
  chacun peut contribuer (les tâches les plus faciles sont gardées
  ouvertes un peu plus longtemps afin de laisser leur chance aux nouveaux
  
negative.code: http://en.wikipedia.org/wiki/Mixin[mixins]. Pour faire simple, il est
  possible de définir des implémentations par défaut dans les
  interfaces/traits (__defender methods__, __virtual extension method__,
  ...). 
  
  J'y reviendrais plus en détails, cher lecteur, dans un prochain
  billet, puisque notre maître à tous, j'ai nommé Brian Goetz, a
  précisément abordé ce thème pendant la conférence *"Language /
  co-evolution in Java SE 8"* auquel j'ai eu le plaisir d'assister. +
   +
  Un exemple d'héritage multiple en Kotlin : +
  
  [source,kotlin]
  ----
  open class Base {
  	virtual fun v() {}     
      fun nv() {} 
  }
  
  open class Base2()
  
  class Derived() : Base2, Base {
  	override fun v() {} 
  }
  ----
  
  On apprécie l'absence totale d'ambiguïté du code précédent. En effet, en
  Kotlin, toute classe non `open` est finale (immutabilité renforcée),
  tout membre overridable doit être déclaré `virtual` (s'il est déjà
  