De nombreux blogs ont déjà relayé les nouvelles fonctionnalités de C# 4.0 (rapidement: le nouveau mot clé "dynamic", les paramètres nommés et optionnels, la co-variance et contra-variance...), je ne vais donc pas m'étaler davantage sur le sujet... Ce post a pour objectif de regarder un peu plus loin que cela, et de faire des hypothèses sur les futures-futures versions ! On sait déjà depuis la PDC 2008 (qui s'est déroulée fin Octobre) ce que seront les deux prochains thèmes du langage... Le premier thème sera le méta-programming: des exemples de ce qui pourrait apparaître ont déjà été dévoilés lors de la PDC08 à la fin de la présentation d'Anders Hejlsberg (que je vous conseille fortement de regarder si vous ne l'avez pas déjà fait).

Le second thème est la cible de cet article :)
Les membres de la C# Team nous en avaient parlé longuement, on regrettera donc l'absence de nouveautés dans C# 4.0 concernant "l'éléphant dans la pièce" (dixit Anders), j'ai nommé le parallélisme, qui auraient pu apparaître sous la forme de nouveaux mots clés pour spécifier l'isolation tels l'immutabilité ou la pureté (c'est aujourd'hui possible via des attributs disponibles publiquement dans la BCL à partir de .NET 4.0, mais ils ne sont pas utilisés à leur juste valeur: pas de vérification statique à la compilation par exemple).

Quel est le rapport entre le parallélisme et ces deux concepts me direz-vous ? Et bien pour pouvoir paralléliser une tâche il faut la découper pour pouvoir assigner chaque morceau à une unité de traitement (un processeur ou un "coeur"). Pour pouvoir découper une tâche il faut s'assurer que ces "morceaux" n'ont pas d'effets les uns sur les autres, autrement dit qu'ils n'ont pas d'effet de bords, et c'est là qu'entre en jeu la pureté et l'immutabilité. On dit d'une méthode qu'elle est pure quand son execution ne modifie pas l'instance de l'objet qui l'execute (qui a dit const ?). On dit d'un type qu'il est immutable lorsqu'aucun champ ni propriété d'une instance de ce type n'est modifiable. Par déduction un type immutable ne peut contenir que des méthodes pures. Par exemple imaginons une classe Point toute bête avec juste un X et un Y. Voici deux manières très différentes conceptuellement d'implémenter cette classe:

public struct Point
{
  public Point(double x, double y)
  {
      this.X = x;
      this.Y = y;
  }

  public double X { get; set; }
  public double Y { get; set; }

  public void Move(double dx, double dy)
  {
      this.X += dx;
      this.Y += dy;
  }
}

public struct Point
{
  readonly double x, y;

  public Point(double x, double y)
  {
      this.x = x;
      this.y = y;
  }

  public double X  { get { return x; } }
  public double Y  { get { return y; } }

  public Point Move(double dx, double dy)
  {
      return new Point(x + dx, y + dy);
  }
}

La première version est classique. La seconde l'est moins: aucun champ n'est modifiable. On créé un objet différent à chaque modification. On peut donc dire de ce type qu'il est immutable: une instance de ce type ne sera jamais modifiée. Cette seconde implémentation vient directement du monde des langages dits "fonctionnels" (dans un monde purement fonctionnel aucune affectation/mutation n'est permise). L'immutabilité et la pureté sont deux concepts qui demandent donc un effort de la part du développeur: un programme ne pourra jamais être parallelisé de manière automatique, avec un flag de compilation par exemple (si vous souhaitez avoir un aperçu de types immutables complexes, accrochez-vous et lisez cette suite de posts fabuleux d'Eric Lippert).

Un ou plusieurs nouveaux mots clés pourraient donc permettre au développeur, dans une future version hypothétique de C#, de spécifier explicitement sa volonté de rendre le code parallélisable pour qu'à la compilation des erreurs soient générées si les conditions de pureté et/ou d'immutabilité n'étaient pas rencontrées. Personnellement je pense que le mot clé "readonly" sera étendu aux classes et aux méthodes... en prends les paris ? Rendez-vous dans 4 ans... ou peut-être en 2009 puisqu'une nouvelle PDC a été annoncée pour 2009 ! Etrange quand on sait que les PDCs se déroulent normalement tous les 2 ans... On vit une époque formidable ;-)

Lire la suite

27/11/2008, update from Singapore : La release de JavaFX, initialement prévue le 2 décembre, est maintenant officiellement fixée au
4 décembre
http://javafx.com/

le billet original était :

Tout est dans le titre ;)
http://blogs.sun.com/theplanetarium/entry/javafx_1_0_release_date

Dans cet article nous allons découvrir cet outil très puissant qu'est le Visual State Manager.

Lire la suite