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 ;-)

Vous en avez certainement déjà tous entendu parlé: la nouvelle version de Silverlight -- le flash-killer de Microsoft -- est sortie aujourd'hui ! Après un interminable développement de plus de 3 ans (souvenez-vous de WPF/E à la PDC 2005...) il est finalement là et pour longtemps :)

Au menu: la possibilité de programmer en .NET grâce à une CLR cross-platform et à un subset de la BCL, un subset de WPF pour le rendu vectoriel, des tonnes de contrôles (calendrier, combobox, textbox, boutons, etc.), la possiblilté de développer en C#, VB, JavaScript, IronPython ou IronRuby... La liste complète et détaillée des features est disponible sur le fabuleux blog de ScottGu. Silverlight 2 est supporté par la quasi-totalité des navigateurs existants (IE, Firefox, Safari, Opéra, Chrome), et la cerise sur le gâteau pour ceux qui esitent encore: la possibilité de développer sous Eclipse !

Non vraiment, on en arriverai presque à croire qu'on est le 25 décembre si tout cela n'était pas offert avec une mauvaise nouvelle pour nous développeurs : la liste complète des breaking changes pour passer de la version Beta 2 à la Release.

Si vous souhaitez commencer à développer dès maintenant c'est par ici et si vous voulez en savoir encore plus sur cette v2 rendez-vous sur le blog de Tim Heuer !

J'entends régulièrement dire -- à tort -- que la sérialisation XML avec Silverlight 2 Beta 1 n'est pas possible, c'est pourquoi j'ai voulu faire ce petit article :)
Pour sérialiser vos objets en XML il suffit d'ajouter dans les références de votre projet l'assembly "System.Xml.Serialization":

Ensuite déclarez par exemple votre classe à serialiser de la manière suivante:

public class Test
{
    [XmlAttribute]
    public string Id { get; set; }
    public int Count { get; set; }
    public string Name { get; set; }
}

Seules contraintes: votre classe doit avoir au moins un constructeur par défaut (ou pas de constructeur du tout) et les propriétés à sérialiser doivent être accessibles en lecture/écriture (ces contraintes n'ont rien à voir avec Silverlight). Libre à vous d'utiliser tout l'armada de sérialisation XML classique (XmlAttribute, XmlIgnore, XmlRoot, etc.). Imaginons ensuite par exemple le code suivant:

public partial class Page : UserControl
{
    public Page()
    {
        InitializeComponent();

        var test = new Test { Id = "titi", Name = "toto", Count = 42 };
        string xml = Tools.XmlSerialize<Test>(test);
        Console.WriteLine(xml);
    }
}

Si on déclare la fameuse méthode de sérialisation de cette manière...

using System;
using System.IO;
using System.Text;
using System.Xml;
using System.Xml.Serialization;

namespace Alti
{
    public static class Tools
    {
        public static string XmlSerialize<T>(T obj)
        {
            var s = new XmlSerializer(typeof(T));
            var stream = new MemoryStream();
            s.Serialize(stream, obj);
            stream.Position = 0;

            var buffer = new byte[stream.Length];
            stream.Read(buffer, 0, (int)stream.Length);

            var utf8 = new UTF8Encoding();
            return utf8.GetString(buffer, 0, buffer.Length);
        }
    }
}

...et qu'on prend la peine de lancer l'application, la magie opère :

<?xml version="1.0" encoding="utf-8" ?> 
<Test xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xmlns:xsd="http://www.w3.org/2001/XMLSchema" Id="titi">
    <Count>42</Count> 
    <Name>toto</Name> 
</Test>

[EDIT] Si les namespaces vous irritent (comme moi), faites plutot:

var ns = new XmlSerializerNamespaces();
ns.Add(string.Empty, string.Empty);
s.Serialize(stream, obj, ns);

ce qui donne:

<?xml version="1.0" encoding="utf-8" ?> 
<Test Id="titi">
    <Count>42</Count> 
    <Name>toto</Name> 
</Test>

Hope this helps !

Aurélien

La sortie de Silverlight 2 est pour nous l'occasion de prendre le train en marche et de nous plonger au coeur du dernier bébé de Microsoft. L'objectif de ce premier post est de découvrir les bases des animations sous Silverlight en créant un projet simple que l'on fera évoluer pas à pas. C'est parti !

Lire la suite