anchor.diff:  compilateur de passer d'un type à un autre sans aucune mention
   explicite. L'exemple le plus connu est `"toto" * 3` qui produit
   `"totototototo"`. +
  +
   Puisque la méthode * n'est visiblement pas définie dans la classe
   `java.lang.String` et qu'il n'existe aucun moyen de l'ajouter (la classe
   est finale), il  suffit de définir cette méthode dans une autre classe,
   disons `StringRepeater` et d'indiquer une conversion implicite entre
   `String` et `StringRepeater` en écrivant comme suit: +
  - +
  -`implicit def myFirstImplicitConversion(str: String) = new StringRepeater(str)` +
  - +
  +
  +[source, scala]
  +----
  +implicit def myFirstImplicitConversion(str: String) = new StringRepeater(str)
  +----
  +
   Quand le compilateur rencontrera une expression du type `"toto" * 3`, il
   cherchera donc toutes les conversions implicites disponibles dans le
   scope courant qui permettent de convertir une `String` vers une instance
  -de classe où la méthode * est définie. +
  - +
  +de classe où la méthode * est définie.
  +
  +
   Cette fonctionnalité est donc très puissante, comme vous l'aurez vu.
   Exploitant au maximum cette possibilité, Mario Fusco a d'ailleurs créé
   le moteur de règles http://code.google.com/p/hammurabi/[Hammurabi] "pour
  
positive.code: ~~~~~~~~~~~~~~~~~~~~~~~
  
  Voici les conférences que ce premier billet va tenter de résumer. +
   +
  
  Nom
  
  Conférenciers
  
  _The Groovy Ecosystem_
  
  Andres Almiray
  
  _Crash Course into Scala_
  
  Mario Fusco et Kevin Wright
  
  _The Kotlin Programming Language_
  
  Andrey Breslav
  
  _The Ceylon Programming Language_
  
  Emmanuel Bernard et Stéphane Épardeau
  
  _Is Fantom light years ahead of Scala?_
  
  Stephen Colebourne
  
   +
  
   +
  
   +
  
  Il ne s'agit en aucun cas d'un compte rendu exhaustif, mais plutôt des
  points qui m'ont marqués (et dont je me souviens encore :P). +
   +
  
  Scala
  ~~~~~
  
negative.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) : +
   +
  
  [source,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 :
  
  [source,kotlin]
  ----
  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
  