J’ai un nouveau pet-peeve [1]. Mais comme pour beaucoup d’entre eux, c’est parce que je me suis longtemps fait avoir. Now that I saw the light, et que je ne me trompe guère plus, voir les autres se tromper m’est tout bonnement insupportable. D’ailleurs mon introduction est amusante, car beaucoup de français ont pour «pet-peeve» l’over utilisation des mots anglais dans une phrase française. Moi qui passe ma journée à lire et à écrire de l’anglais, ça ne me choque plus, vous savez.

Maintenant que vous, fidèle lectorat de Codingly, êtes tiraillé par le suspens, je me vois mal vous expliquer que c’est la mauvaise utilisation d’un mot qui cause toute cette ire. Et pourtant, ce matin encore, en lisant mon greader, j’ai failli en recracher mon thé équitable. Une personne de plus dans l’erreur, bordel ! J’en ai ouvert mon Word, et me voici deux paragraphes plus tard. Oui, j’en viens au cœur du problème. Problème que l’apparition de C#4 n’a pas manqué de raviver.

Prenons un exemple de code, compréhensible par tous de 7 à 77 ans. Exception faite de Patrick Smacchia qui dominait la scène démo bien avant cet âge.

public static void DoFoo ()
{
    string a = "b";
    string b = "b2";
    string c = "g";
    Foo (a, b, c);
}

public static string Foo (string bar, string baz, string gazonk)
{
    return bar + baz + gazonk;
}

Ce code n’a, je vous l’accorde, ni queue ni tête, et ne sert que le besoin de ma démonstration. Ne nommez pas vos variables ainsi (en plus vous devriez utiliser var, on voit bien que c’est un string). Ne refaites donc pas ça au travail. Chez vous, par contre, je dis pas, vous faites ce que vous voulez chez vous après tout.

Bref, détaillons rapidement ce petit bout de code. La méthode Foo a trois paramètres, bar, baz et gazonk. La méthode DoFoo déclare trois variables a, b et c, et appelle la méthode Foo en lui passant en argument le contenu de ses trois variables respectives.

Jusque ici, rien de bien terrible. Utilisons les nouveautés de C#4 maintenant.

public static void DoFoo ()
{
    string a = "foo";
    Foo (a);
    Foo (a, gazonk : "GazouGazou");
}

public static string Foo (string bar, string baz = "baz", string gazonk = "gaz")
{
    return bar + baz + gazonk;
}

C’est vrai que c’est amusant. Relisons encore ce que nous voyons. La méthode Foo a toujours trois paramètres, bar, baz et gazonk. Cependant, baz et gazonk ont maintenant une valeur d’argument par défaut. Pour le paramètre baz, la valeur "baz" sera passée comme argument par défaut si l’appelant n’en fournit pas, d’argument. Et de même pour le paramètre gazonk, qui aura comme argument par défaut la valeur "gaz".

La méthode DoFoo devient elle aussi plus intéressante. Elle appelle la méthode Foo deux fois. La première fois en passant un seul argument à Foo, le contenu de la variable a. Point besoin de passer d’autres arguments : le compilateur C# le fera à votre place. En examinant la signature de Foo, pour chaque paramètre définit par Foo, le compilateur va utiliser les valeurs nouvellement spécifiées comme valeurs d’arguments par défaut. Il n’y a donc pas besoin de passer d’argument pour les paramètres baz et gazonk. Après tout, c’est pour ça qu’on les appelle arguments par défaut.

Le deuxième appel à Foo est tout aussi intéressant. Non seulement on passe toujours comme argument le contenu d’une variable pour le paramètre a, mais en plus on spécifie clairement un argument, la valeur "GazouGazou" en le nommant, gazonk, d’après le paramètre définit dans la signature de la méthode Foo auquel on envie que le compilateur C# applique l’argument.

Oh je vous entends d’ici :

Tu nous saoules Jb, ça fait mille ans que c’est sorti C#4, et presque autant que je peux les utiliser avec Mono. En plus c’est super fastidieux ton explication, t’appuies sur tous les mots comme un gamin sur son jouet fisher price.

Et vous auriez raison. Mais les trucs fastidieux c’est un peu la raison d’être, comme disent les anglais, de Codingly. Donc mon article a tout à fait sa place.

De toute façon personne n’a rien compris, c’est pas un post sur comment ça marche les arguments nommés en C#4 et les arguments par défaut. C’est un post sur la bonne utilisation des mots « paramètre » et « argument » que tout le monde s’amuse à mélanger à loisir, et ce faisant, à ruiner mon bon moral dès le matin. Vous pourriez d’ailleurs aller lire Wikipedia ils expliquent mieux que moi.

Vous ne vous rendez pas compte, même les speakers aux TechDays se mélangent les pinceaux. Il y aurait eu des caténaires entre Lyon et Paris ce jour là, je me serais probablement évanoui dans la salle.

Récapitulons, donc :

• Les paramètres nommés ne sont pas une nouveauté de C#4, depuis C#1 les paramètres ont des noms, enfin ! Un paramètre est un élément de la signature d’une méthode.
• Un argument désigne la valeur passée à un paramètre. On peut maintenant nommer les arguments pour gagner en lisibilité. On peut aussi les omettre quand un paramètre définit une valeur d’argument par défaut.

C’est compris, OK ?

[1] Un «pet-peeve», comme vous ne manquez pas de le savoir, c’est quelque chose qui vous irrite sans que vous puissiez le contrôler de manière rationnelle.

Do I care if it’s Predicate<int> or Func<int>? No, than why won’t C# compiler just live me alone and pick whatever it needs? I DONT CARE

Et là je me dis HAHA LOL MAIS N’IMPORTE QUOI Predicate<int> et Func<int> c’est très différent voilà une bonne occasion pour moi qui ne suis rien de reprendre gratuitement un des contributeurs principaux de Castle sur une étourderie. Et je lui fais remarquer, en gros :

Pardon, mais en fait, je crois que Predicate<int> et Func<int> sont des délégués bien différents :)

Et tac ! Bon, évidemment, Krzystzof Kzrysztof Krzysztof pensait bien à Func<int, bool> qui partage effectivement la même signature que Predicate<int>. Son commentaire, pertinent, est donc celui d’un programmeur pestant contre le fait que les délégués, en C#, et au niveau même de la CLI, soient des types nominatifs et non structurels.

Considérons les deux types suivants :

    class Tweet
    {
        public string Message;
    }

    class Buzz
    {
        public string Message;
    }

Nous sommes alors ravis de ne pouvoir écrire :

    Tweet tweet = new Buzz();

Car même si structurellement, les instances de Tweet peuvent être considérées compatibles avec les instances de Buzz, sémantiquement c’est une autre histoire. Les points en coordonnées cartésiennes ne sont pas des points en coordonnées polaires, les chiens ne sont pas des chats, etc.

Dans le CLR, tous les types sont nominatifs, et c’est très bien comme ça. Sauf quand ce n’est pas très bien ; Krzysztof et moi pensons par exemple aux délégués.

Le premier problème est qu’il est impossible de convertir implicitement une instance de delegate en un autre type de delegate structurellement compatible, e.g. : on ne peut pas « convertir » une instance de Func<int, bool> en Predicate<int> :

    Func<int, bool> func = i => false;
     
    // La ligne ci-dessous lève une erreur de compilation :
    // Cannot implicitly convert type 'System.Func<int,bool>' to 'System.Predicate<int>'
    Predicate<int> predicate = func;

Cependant, il existe plusieurs façons de contourner le problème, dont une particulièrement acceptable :

EventHandler eventHandler = (s, e) => {};
Action<object, EventArgs> action;

action = (s,e) => eventHandler(s,e); // OK, mais lourd.
action = new Action<object, EventArgs>(eventHandler); // OK, mais verbeux.
action = eventHandler.Invoke; // OK tout court.

Notons que les deux dernières lignes produisent le même code IL, puisqu’on laisse simplement le compilateur générer automatiquement l’appel au constructeur de Action<object, EventArgs> à partir du method group Invoke compatible. Quels que soient donc les types de délégués structurellement compatibles avec lesquels on joue, la « conversion », certes explicite, ne coutera que 7 caractères. C’est 133 de moins qu’un tweet.

Le second problème, plus gênant selon moi, est qu’il est impossible aujourd’hui de comparer les références de deux instances de délégués structurellement compatibles mais de types différents, alors que selon la sémantique de l’opérateur d’égalité de Delegate, ça ne devrait pas être gênant :

Predicate<string> predicate1 = string.IsNullOrEmpty;
Predicate<string> predicate2 = string.IsNullOrEmpty;
Func<string, bool> func = string.IsNullOrEmpty;

if (predicate1 == predicate2) // Vrai
    Console.WriteLine("predicate1 == predicate2");

if (predicate1.Equals(func)) // Faux
    Console.WriteLine("predicate1 == func");

Note : Une ancienne version de la spécification C# laisse entendre que c’était possible :

Note that delegates of different types can be considered equal by the above definition, as long as they have the same return type and parameter types.

Mais dans la dernière version spécifie explicitement que c’est impossible :

If the delegates have different runtime type they are never equal.

Bref.

Les plus curieux peuvent alors se demander pourquoi Microsoft n’a pas choisit de faire des delegates des types structurels. Lorsqu’on se pose une question de ce genre — et j’en profite, amis lecteurs, pour vous poser une petite devinette — à qui est-il intéressant de la soumettre :

• Eric Naulleau ?
• Eric Zemmour ?
• Eric Lippert ?

Bravo amis lecteurs, c’est effectivement à M. Zemmour que j’ai envoyé un mail. Voici donc un extrait de sa réponse :

In practice, almost everyone uses delegates structurally, and almost no one makes semantic distinctions between different kinds of delegate types. There’s no semantic reason why Predicate and Func couldn’t be used interchangeably; they are interesting solely for their structure. (Though of course it is nice if a predicate is a pure function!)

If we had a chance to do it all over again, I think we would make delegates into structural types. Also, note that the new « no PIA » feature of C# 4 is essentially structural typing on interfaces. We probably erred a little too far on the side of caution when making all types non-structural in CLR v1, and now we’re gradually weakening that. I would not be too surprised if in some future version of the CLR, it was easier to make structural delegate types, but, no promises. That’s just a speculation.

En deux mots, Eric Lippert (oui car en fait c’est Eric Lippert, hein), m’a répondu qu’il serait tenté de faire passer les delegates du côté des types structurels s’il en avait l’occasion, et qu’il ne serait pas forcément étonné si cela arrivait dans une version future du CLR.

Stay tuned !

    switch(expression.GetType().FullName)
    {
        case "System.Linq.Expressions.ConstantExpression":
            VisitConstantExpression((ConstantExpression) expression);
            break;
        case "System.Linq.Expressions.MemberExpression":
            VisitMemberExpression((MemberExpression) expression);
            break;
        case "System.Linq.Expressions.MethodCallExpression":
            VisitMethodCallExpression((MethodCallExpression) expression);
            break;
        case "System.Linq.Expressions.LambdaExpression":
            VisitLambdaExpression((LambdaExpression) expression);
            break;
        default:
            VisitExpression(expression);
            break;
    }

Aussi, si j’étais comme tout le monde (note: je ne suis pas comme tout le monde), je ferais une blague à propos de Dieu qui tue des animaux mignons à chaque fois que vous écrivez quelque chose comme :

    if(expression is ConstantExpression)
        VisitConstantExpression((ConstantExpression)expression);
    else if (expression is MemberExpression)
        VisitMemberExpression((MemberExpression)expression);
    else if (expression is MethodCallExpression)
        VisitMethodCallExpression((MethodCallExpression)expression);
    else if (expression is LambdaExpression)
        VisitLambdaExpression((LambdaExpression)expression);
    else
        VisitExpression(expression);

La bonne solution, même si elle paraitra moins concise aux plus taquins d’entre vous, est la suivante :

    var constantExpression = expression as ConstantExpression;
    if (constantExpression != null)
    {
        VisitConstantExpression(constantExpression);
        return;
    }

    var memberExpression = expression as MemberExpression;
    if (memberExpression != null)
    {
        VisitMemberExpression(memberExpression);
        return;
    }

    var methodCallExpression = expression as MethodCallExpression;
    if (methodCallExpression != null)
    {
        VisitMethodCallExpression(methodCallExpression);
        return;
    }

    var lambdaExpression = expression as LambdaExpression;
    if (lambdaExpression != null)
    {
        VisitLambdaExpression(lambdaExpression);
        return;
    }

    VisitExpression(expression);

Le safe cast évite la redondance is + cast. Rendons tout de même à césar ce qui est aux taquins : c’est un peu verbeux. Heureusement, il est assez facile de factoriser ce genre de code. J’utilise pour ma part une implémentation à base de méthodes d’extensions, qui ressemble à :

    public class Switch
    {
        public object Target { get; set; }

        public Switch(object target)
        {
            this.Target = target;
        }
    }
    
    public static class SwitchExtensions
    {
        public static Switch Case<T>(this Switch @this, Action<T> action) where T : class
        {
            if (@this == null)
                return null;

            var t = @this.Target as T;
            if (t == null)
                return @this;

            action(t);
            return null;
        }

        public static void Default(this Switch @this, Action action)
        {
            if (@this == null)
                return;

            action();
        }
    }

On retombe alors à l’utilisation sur quelque chose de concis et lisible :

    new Switch(expression)
        .Case<ConstantExpression>(VisitConstantExpression)
        .Case<MemberExpression>(VisitMemberExpression)
        .Case<MethodCallExpression>(VisitMethodCallExpression)
        .Default(() => VisitExpression(expression));

Chaque case prend un délégué en argument. Ici, comme Action<T> matche à chaque fois la signature des méthodes que je veux appeler (Visit*), je passe directement les method groups. Notez qu’il est tout à fait possible de faire autrement :

    new Switch(expression)
        .Case<MemberExpression>(e => Console.WriteLine("MemberExpression : " + e))
        .Case<MethodCallExpression>(e =>
                                    {
                                        Console.WriteLine("Rofl");
                                        VisitMethodCallExpression(e);
                                        Console.WriteLine("Lfor");
                                    });

Enfin, pour ne pas que vous vous sentiez trop lésés par cet articlet, voici en prime une photo de pingouin :

—  A quoi ça sert, le mot clé event ?
—  Bah, à déclarer des events.
—  Oui, mais ça marche pas sans le mot clé event ? En écrivant juste, par exemple :
  public EventHandler Click;
—  Heu, si, je crois.
—  Donc, à quoi ça sert, le mot clé event ?
—  T’es relou, dégage.

Notez qu’à l’oral, il n’y a pas la coloration syntaxique. Je suppose que c’est ce qui conduit assez régulièrement mes interlocuteurs à être désagréables. (J’aime pas les gens désagréables !)

Au risque donc que vous commenciez à m’appeler Monsieur Mauclet, j’ai bien envie de regrouper dans ce post les principales différences qui existent entre :

public EventHandler Click;

Et :

public event EventHandler Click;

Et de combattre au passage certaines confusions, parce que je me sens l’âme d’un chevalier en ce moment.

Tout d’abord — et c’est la différence fondamentale dont découle la plupart des autres — un event (syntaxiquement assimilable à un champ de type delegate modifié par le mot clé event) n’est pas un champ. Il s’agit plutôt d’une sorte de propriété un peu spéciale revêtant une sémantique particulière : un event est explicitement, heh, un évènement.

Concrètement, écrire :

public event EventHandler Click;

Est équivalent à :

private EventHandler click;
public event EventHandler Click
{
	add { this.click += value; }
	remove { this.click -= value; }
}

Le code ci-dessus est valide en C#. Par défaut, un évènement possède des « accesseurs », add et remove, qui permettent respectivement d’ajouter et de supprimer des handlers à un champ privé, de type delegate. Notez qu’il s’agit ici de l’implémentation générée par le compilateur lorsque vous utilisez la déclaration classique d’un event, mais il est tout à fait possible de changer cette implémentation : vous êtes en effet libre de mettre ce que vous voulez dans le add et le remove. A vrai dire, un event n’est que ce couple add/remove.

Exemple !utile :

private EventHandler click;
private int handlerCount;
public event EventHandler Click
{
	add 
	{ 
		this.click += value; 
		this.handlerCount++;
	}
	remove
	{ 
		this.click -= value; 
		this.handlerCount--;
	}
}

Il est intéressant de faire l’analogie entre la façon usuelle de déclarer un event et l’écriture d’une propriété automatique. Dans les deux cas, le compilateur fait le grunt work, et se charge donc de générer le backing field encapsulé par l’event ou la propriété, ainsi que la logique associée (affectation/lecture de la valeur ou ajout/suppression du handler), parce que la plupart du temps, c’est effectivement ce que l’on désire. Dans les deux cas, au risque de me répéter, il est possible de reprendre la main et de faire ce que l’on veut en proposant une implémentation différente des accesseurs (get/set pour les propriétés, add/remove pour les events).

En résumé, un event n’est pas un champ, un delegate, ou un truc de facebook ; non, un event en C# est un moyen d’exposer de façon normalisée, deux méthodes permettant d’enregistrer/désenregistrer des handlers. C’est tout.

Je crois qu’il faut bien faire la différence entre ce qu’est un event par définition, et ce que le compilateur génère par défaut pour nous aider. On peut très bien déclarer un event sans avoir de backing field, comme c’est aussi le cas pour les propriétés. Un-event-c’est-deux-méthodes.

Bon.

Après ce petit rappel, on devrait se sentir un peu plus à l’aise pour commencer l’énumération inutile de tout ce qui distingue plus ou moins évidemment un event d’un Champ Public De Type Delegate (CPDTD).

Protection

Lorsque vous exposez un CPDTD, n’importe qui est capable de le référencer et de le manipuler en tant que tel. Ce n’est pas le cas lorsque vous déclarez un event, puisque seules deux méthodes d’ajout/suppression de handler sont exposées. Du coup, l’invocation d’un event est restreinte : seul le type qui porte l’évènement peut déclencher ce dernier, les autres types devant se contenter de fournir leurs handlers en utilisant modestement les accesseurs.

Attention, même les types dérivés perdent le privilège d’invocation; on devra donc la plupart du temps prévoir une méthode protected pour contourner la limitation.

Interfaces

Puisqu’un event-c’est-deux-méthodes, il peut apparaitre dans une interface, alors qu’un CPDTD, non. C’est très important, et très logique. Il est compréhensible en effet qu’on puisse s’engager à « exposer » deux méthodes dans un contrat, mais pas un champ.

Polymorphisme

Puisqu’un event-c’est-deux-méthodes, toujours, on peut parler de polymorphisme, et appliquer aux events les modifiers qu’il est habituellement possible d’appliquer aux méthodes. Implicitement, ils concerneront les deux accesseurs add et remove. Cela signifie qu’un event peut être abstract, virtual ou même sealed. De même, on peut overrider ou redéfinir un event à l’aide des mots clés override et new.

Pas le droit lol

Le fait qu’un event ait toujours des accesseurs (add/remove) implique que les fonctions correspondantes existent déjà. Ainsi, il est impossible d’écrire :

public event EventHandler Click;

public void add_Click(EventHandler handler) {} // Erreur : signature existante
public void remove_Click(EventHandler handler) {} // Erreur : signature existante

Opérateurs

Lorsqu’utilisés avec les delegates, les opérateurs += et -= ne sont pas interprétés comme la combinaison condensée d’une addition/soustraction + une affectation. le type Delegate ne surcharge d’ailleurs ni l’opérateur +, ni l’opérateur -. En fait, le compilateur remplace += et -= par les appels respectifs aux méthodes statiques Delegate.Combine et Delegate.Remove, qui retournent de nouvelles instances de délégués. (Un délégué est immutable)

Par contre, lorqu’on utilise += et -= pour ajouter/supprimer un handler à un event, le compilateur travaille différemment et se charge d’appeller directement les accesseurs de l’évènement.

Si Click est un CPDTD :

button.Click += OnClick;
// Compilé en :
// button.Clik = (EventHandler) Delegate.Combine(button.Clik, new EventHandler(OnClick));

Si Click est un event :

button.Click += OnClick;
// Compilé en :
// button.add_Click(new EventHandler(OnClick));

Warnings

Puisqu’il est uniquement possible de déclencher un évènement à l’intérieur de la classe qui contient sa déclaration, le compilateur est capable de lever un warning lorsqu’il ne détecte aucune invocation de l’évènement.

Evaluation

En C#, une affectation est une expression évaluable. On peut écrire, par exemple :

int i = 12;
int j = i = 6; // (i = 6) est évalué, de type int, donc le code est valide et j vaudra 6.

De même, lorsque Click est un CPDTD, il est possible décrire :

EventHandler handler = button.Click += OnClick;

Car l’expression button.Click += OnClick est de type EventHandler.

Mais dans le cas où Click est un event, button.Click += OnClick est de type void, du coup le code précédent ne compile pas.

Reflection

Si on veut accéder à un CPDTD par la réflexion, on utilise la méthode GetField ou GetFields. Mais comme les events sont des animaux bien différents, il existe les méthodes GetEvent et GetEvents, qui retournent des instances d’EventInfo. J’ai insisté là dessus précedemment : la notion d’event n’est liée à celle de backing field que parce qu’il s’agit d’une association constatée dans 99% des implémentations, mais c’est tout. Il est impossible d’optenir les métadonnées relatives au backing field d’un event à partir de son EventInfo, tout comme il est impossible d’obtenir les métadonnées relatives au backing field d’une propriété à partir de son PropertyInfo.

Enfin si, c’est possible, mais chut.

Interop

Si vous kiffez COM, sachez que les CPDTD ne vous seront d’aucune utilité au cas où vous chercheriez à interopérer avec des évènements COM. Il faudra forcément utiliser des events. Et ne me dites pas que c’est évident, où je vous tue.

Doudounotte

Microsoft propose une guideline relative aux events :

…the delegate type used for an event should take two parameters, an « object source » parameter indicating the source of the event, and an « e » parameter that encapsulates any additional information about the event. The type of the « e » parameter should derive from the EventArgs class. For events that do not use any additional information, the .NET Framework has already defined an appropriate delegate type: EventHandler.

Ce n’est qu’un encouragement, hein, vous êtes libre d’avoir des events de type Action<Func<Dictionary<string, List<uint>>, Guid>, bool> si vous le souhaitez. Néanmoins, l’idée est louable, puisque si le conseil est suivi, la contravariance permettrait à la méthode suivante de devenir un handler universel :

public void OnEvent(object sender, EventArgs e)
{
}

Je suppose que c’est l’ambition très secrète de toutes les méthodes du monde. En tout cas, si j’étais une méthode, l’idée me séduirait.

Synchronisation

Pour les events, lorsqu’on laisse le compilateur générer le backing field et les accesseurs, ces derniers seront automatiquement synchronisés. Le compilateur associera en effet l’attribut MethodImpl avec l’option MethodImplOptions.Synchronized aux méthodes add et remove, ce qui est fonctionnellement équivalent à prendre un lock sur l’instance ou le type, selon si l’event est ou non statique.

Par contre, si vous préférez fournir votre propre implémentation pour les accesseurs, ce sera à vous de prévoir la synchronisation en utilisant un lock manuellement, si nécessaire.

Merci Patrice !

Menteur

Si un event n’est que deux méthodes, comment se fait-il alors, gros malin, que l’on puisse écrire et compiler :

public event EventHandler Click;

public void ICanHazInvokashun()
{
    Click(this, EventArgs.Empty);
}

En effet, un évènement est bien invocable. Ca voudrait dire que le compilateur est capable de tricher, et d’appeler sournoisement la méthode Invoke sur le champ privé caché ? Et bien oui. Le pseudo IL du corps de ICanHazInvokashun ressemble à :

ldarg.0 
ldfld class System.EventHandler Button::Click
ldarg.0 
ldsfld class System.EventArgs System.EventArgs::Empty
callvirt instance void System.EventHandler::Invoke(object, class System.EventArgs)
ret

A la ligne 2 on constate que c’est bien un champ (ldfld = load field) qui est poussé sur la pile et sur lequel on appelle la méthode Invoke (ligne 5). A quoi d’autre pouvions-nous nous attendre ?

Si on décide de fournir une implémentation différente pour add et remove, le compilateur ne devrait plus être en mesure de permettre l’invocation directe de l’évènement avec la même syntaxe :

public event EventHandler Click
{
    add { /* rien */ } remove { /* pas mieux */ }
}

public void ICanHazInvokashun()
{
    Click(this, EventArgs.Empty); // Haha j't'ai foolé, sale compiler.
}

Effectivement, il n’est plus possible de compiler la ligne 8, et on obtient le message d’erreur généralement réservé aux utilisateurs du type qui expose l’évènement :

The event ‘Button.Click’ can only appear on the left hand side of += or -=

Voilà. Certes, c’était un post un peu facile, et tout ça n’est pas très excitant. Mais après tout, qu’est-ce qui peut bien être excitant en C# ? On parle d’un langage de programmation ! Alors à moins d’être un fanboy, etc.

From my latest Inc. column : « Blah blah blah »

Bon, moi, je ne suis pas Joel Spolsky car je n’ai pas tenu 10 ans avant de sauter le requin.

Extrait de mon dernier compte-rendu sur altnetfr.org :

Par contre, Yann ne sait pas coder :

for(int i=0; i< 100000000; i++)
{
   if(!list.Contains(Guid.NewGuid().ToString()))
      list.Add(Guid.NewGuid().ToString());
}

Il faut probablement avoir une maladie mentale pour écrire ça ! C’est en tout cas ce que j’ai pensé sur le coup, en pouffant sur ma chaise (j’étais au fond de la salle). Ensuite, je ne sais plus si je l’ai compris de moi même ou si Yann a dû le préciser d’un air atterré, mais il avait fait exprès d’écrire ça. Parce que d’autres ne font pas exprès, et que ça pose des problèmes.

C’était au sujet de la dernière rencontre ALT.NET parisienne, où Yann Schwartz nous parlait de Windbg et d’autres trucs. C’était très bien.

Bon, pour ma part j’ai trouvé que ça s’était plutôt bien passé considérant que je ne suis pas un speaker – au mieux un sale programmeur – même si j’imaginais une présentation un peu plus courte. J’ai parlé pendant 45 min, je crois, puis j’ai ouvert VS pour la « démo interactive » qui s’est un peu éternisée.

Je tiens encore à remercier FastConnect pour la salle, l’organisation, le buffet, etc.

En ce qui concerne le code des exemples, j’essaierai d’éditer ce post ultérieurement.

Edit Quelques liens en rapport :

• INotifyPropertyChanged avec PostSharp
• INotifyPropertyChanged avec Mono.Cecil

Edit Le compte rendu de la soirée est maintenant dispo sur le site ALT.NET Fr. Merci Jb.

N’hésitez pas à me faire part de vos critiques positives, puisque les autres, constructives ou pas, elles vexent. OK ?

Je voulais vous informer, ou plus probablement vous rappeler, que j’allais commettre une présentation sur l’AOP, le 17 juin, à l’occasion de la 14ème rencontre ALT.NET Parisienne. Vous trouverez les détails pratiques sur notre joli site. Merci à FastConnect qui sponsorise l’évènement.

Il va sans dire que je serais plus à l’aise s’il n’y avait que 3 personnes qui jugeaient bon de se déplacer. Pourtant, je vais m’asseoir sur cette considération et vous inviter à venir nombreux. Plusieurs fois au cours des rencontres précédentes nous avons abordé la question de la programmation orientée aspect lors des discussions libres, et il semblerait donc que le sujet rende curieux, à défaut de préoccuper. Peut-être mérite-t-il que nous lui fassions plus de place le temps d’une soirée. Je ne sais pas encore exactement quel sera l’agenda, mais l’idée est de présenter l’AOP en tant que concept, de le confronter gentiment aux paradigmes traditionnels, avant de passer plus concrètement à l’étude des différentes techniques et outils qui existent en .NET.

D’aucuns pourraient penser que le sujet n’est pas spécialement ALT.NET.

Ce à quoi je répondrais :

Certes, certes…

Enfin. Si on compte uniquement sur Microsoft pour profiter de l’AOP on risque assez rapidement de se sentir à l’étroit. Il est possible de faire de l’AOP sans sortir de la BCL, oui, et il est possible de faire de l’AOP un peu plus facilement en débordant sur EntLib. Cependant, les solutions les plus matures et les plus riches pour faire de l’AOP en .NET ne sont pas forcément estampillées Microsoft, ce qui risque de conduire l’utilisateur averti vers des frameworks plus spécialisés, open-source ou pas. Je veux parler de Castle.DynamicProxy, PostSharp, Linfu, Mono.Cecil, Spring.NET, etc.

Moi, je trouve que ça sent ALT.NET.

Bref, j’espère que cette rencontre verra naitre un débat et que nous pourrons collecter quelques retours d’expériences, comparer nos approches, bailler, etc. Encore une fois, toutes les infos sont disponibles sur le site altnetfr, à cette adresse.

Pensez à vous inscrire, et n’hésitez pas à faire passer l’info.

EDIT : Ce post est un poisson d’avril, évidemment. Il vaudrait mieux ne pas utiliser l’implémentation du disposing pattern proposée…

Quelques rappels

On parle de code managé en .NET car on fait implicitement référence au garbage collector qui gère automatiquement la mémoire. Il n’est pas question de faire un cours sur le GC, mais retenez juste qu’il est très intelligent, et qu’il est indépendant. Tellement indépendant qu’on ne peut pas prévoir quand est-ce qu’il va réellement effectuer son recyclage. Par exemple, lorsque vous écrivez :

public int Add(int a, int b)
{
    Calculator calculator = new Calculator();
    return calculator.Add(a, b);
};

Vous créez une nouvelle instance de Calculator qui sera référencée par la variable locale calculator. A la sortie de la méthode, la variable locale n’existe plus, et l’instance de Calculator n’est donc plus référencée. L’espace mémoire qu’elle occupe peut être récupéré, et le GC le sait. (Notez l’assonance.) Il y a un instant j’insistais sur l’indépendance du garbage collector : s’il sait qu’il peut libérer une instance, vous ne savez pas quand il le fera.

On considère que la collecte des miettes est indéterministe. Vous n’avez aucun moyen de savoir précisément quand le calculator que vous avez instancié précédemment sera collecté. Ca ne sera pas forcément à la sortie de la méthode, comme on pourrait naïvement s’y attendre ; ça peut être 47 ms ou 47 secondes après (pour caricaturer) et vous devriez même être heureux de ne pas avoir à vous en soucier.

Mais.

Tout n’est pas managé. Parfois, vous utilisez à partir d’objets managés des ressources non managées. Même si ça peut paraitre évident, il est bon de revenir là dessus. On parle de « ressource non managée » dans ce contexte pour décrire une ressource :

• Dont l’allocation est déclenchée à partir de votre code managé.
• Qui doit être libérée.
• Mais dont le garbage collector n’est pas responsable.

Les handles de fichiers, les connexions de bases de données, les sockets réseau ou les références COM sont des exemples de ressources non managées.

Comment implémenter le disposing pattern

On se base sur l’interface IDisposable, et sur les destructeurs de C#. IDisposable expose une méthode Dispose, qui va détruire l’objet, et faire en sorte que sa mémoire soit désallouée du heap (et non pas de la pile comme je le vois souvent dans des blogs), surtout si on fait bien appel au mot clé using qui ne sert pas qu’à importer des namespaces.

Mais assez de théorie, passons au code. Imaginons la classe C# suivante, et regardons comment elle fait pour libérer le IntPtr qu’elle a en variable publique et qui constitue sa variable non managée dangereuse (attention aux memory leaks lol) :

EDIT : Ce post est un poisson d’avril, évidemment. Il vaudrait mieux ne pas utiliser l’implémentation du disposing pattern proposée…

public class MaClasseManagée : IDisposable // on implémente IDisposable
{
    private IntPtr m_Ressource_non_managée; // Attention !
	bool disposed = false; // pour savoir si la classe est libérée  

    public MaClasseManagée(IntPtr ptrnonmanagé)
    {
		if(ptrnonmanagé != null)
		{
			m_Ressource_non_managée = ptrnonmanagé; // allocation mémoire non managée
		}
		else // sinon
		{
			if (ptr.Equals(IntPtr.Zero) == true)
            {
                // on désalloue directement la mémoire du pointeur
				m_Ressource_non_managée = IntPtr.Zero
            }
			GC.CancelFullGCNotification(); // pas obligé, mais il vaut mieux
		}
    }

	public void FaireQuelqueChose()
	{
		// ici on utilise la ressource non managée qui a été allouée
		// ...
		// ...
	}

	// destruteur de la class
	~MaClasseManagée()
	{
		// partie un peu tricky : on interdit au CLR de supprimer l'instance
		// courante car ça a déjà été fait dans le Dispose d'IDisposable
		GC.SuppressFinalize(this);
		
		// on s'assure quand même qu'on garde pas de référence vers le pointeur
		m_Ressource_non_managée = IntPtr.Zero;
	}
	
	// methode dispose la plus importante
    public void Dispose()
    {
        if(!disposed)
        {
			// on appelle le garbage collector, et on force la libération de 
			// tous les objets pour être certains de plus référencer des variables
			// non managées depuis C#
			GC.Collect();
			
			disposed = true; // déja disposé
        }
    }
}

Notez donc qu’il faut bien faire la différence entre le constructeur, le destructeur, et le dispose. Trop souvent les gens oublient l’un des trois, et compromettent du coup la sécurité de leur code.

A l’utilisation c’est simple :

// mot clé using
using(MaClasseManagée obj = new MaClasseManagée())
{
	// manipuler obj
	obj.FaireQuelqueChose();
} 
// à la sortie du bloc using, le garbage collector est appellé et libère le tas
// des instances de MaClasseManagée persistantes, donc, forcément avec notre
// pattern, des ressources non managées IntPtr aussi

Et voilà :)

Je compte faire un article bientôt sur une nouvelle façon d’appréhender cette problématique avec l’AOP, notamment dans les architectures distribuées où il y a trop de code à écrire pour qu’on puisse se permettre de perdre du temps avec ces considérations bas niveau dans un contexte économique délicat (c’est la crise !) qui nous force à économiser le temps et l’argent sans pour autant arrêter de produire des logiciels de qualité qui donneront satisfaction au client et permettront aux développeurs de ne pas s’arracher les cheveux sur des solutions de 50 projets où les autres ont fait n’importe quoi et qu’il faut quand même livrer coute que coute tant pis pour les nuits blanches (ça serait quand même un comble de ne plus être en mesure de maitriser son métier, ou de devoir arrêter la qualité sous prétexte que c’est les chefs de projets qui décident des planning sans rien comprendre de la technique alors que c’est la base).

www.altnetfr.org

Update 24/06/2017 : Bon, maintenant, c’est un-site-chinois !

ALT.Net est un groupe de développeurs .NET passionnés, cherchant à améliorer la façon dont les logiciels sont développés. Nous reconnaissons qu’il n’y a pas de solution unique à un problème mais qu’il y a une multitude d’alternatives pouvant être appliquées dans différentes situations.

Le but était d’offrir une façade à la communauté ALT.NET de France. Jusqu’alors il fallait être spécialement motivé pour parvenir à comprendre ce qu’était ALT.NET, et encore un peu plus pour oser venir aux rencontres. Le nouveau site devrait donc répondre à ces deux besoins, en décrivant le mouvement et ses principes d’une part, et en proposant l’agenda des différents évènements que nous organisons d’autre part.

La dernière réunion a permis à Nicolas Roux et Frédéric Fadel de nous présenter Aspectize, et un compte rendu a déjà été posté par Gauthier. En Mars, il sera question de TDD, et c’est Djamel Zouaoui et Frédéric Schäfer qui animeront la présentation dans les locaux d’Octo. Nous comptons continuer de la sorte en annonçant les réunions futures et en proposant des comptes-rendus régulièrement. N’hésitez d’ailleurs pas à soumettre vos contributions ; un effort collaboratif ne peut qu’être profitable.

Pour ceux qui ne sont pas spécialement enclins à rédiger des comptes-rendus ou à proposer des articles, notez qu’il existe un wiki, qui offre déjà à tous la possibilité de participer sans contrainte particulière à l’enrichissement des ressources ALT.NET en français.

Bref, vous êtes chaudement invités à :

• Ajouter altnetfr.org dans vos readers
• Proposer vos comptes-rendus, vos articles, etc.
• Venir à la prochaine réunion (et aux autres)
• Faire passer le mot au sujet d’ALT.NET France !
]]> https://codingly.com/2009/03/02/nouveau-site-pour-altnet-france/feed/ 5 Romain https://codingly.com/2009/01/15/si-les-types-etaient-des-animaux-typedreference-serait-un-ornithorynque/ https://codingly.com/2009/01/15/si-les-types-etaient-des-animaux-typedreference-serait-un-ornithorynque/#comments Thu, 15 Jan 2009 00:08:29 +0000 http://codingly.com/?p=535 Devinette : C’est un type valeur, mais on ne peut pas le caster en object. Il est impossible d’en déclarer des tableaux. On ne peut l’utiliser que pour typer les paramètres de méthodes et les variables locales. Il existe 4 mots clés non documentés en C# qui lui sont directement reliés, et autant d’opcodes en CIL. Il permet notamment le support des varargs, et exactement 8 personnes dans le monde se sont souciées plus de 5 min de son existence.

Je veux parler, bien évidemment, de TypedReference. Je vous propose de découvrir ce type à partir d’un exemple rigolo.


Méthodes varargs et interopérabilité

En C#, lorsqu’on veut définir une méthode à nombre de paramètres variables, on utilise la syntaxe suivante :

public static double Average(params int[] values)
{
    double sum = 0;
    foreach (var i in values)
        sum += i;
    return sum / values.Length;
}

Notez le mot clé params qui permet l’appel de la méthode en passant un tableau en paramètre, ou en listant plus librement les arguments :

var parameters = new int[]{45, 68, 97, 45};
ManagedClass.Average (parameters)
// ou bien
ManagedClass.Average (45, 68, 97, 45)

En C++ / CLI, la syntaxe est un peu différente mais le principe est le même :

double CodinglyInterop::CppCliLibrary::average(... array<int,1> ^values)
{
	double sum = 0;
	for each (int i  in values)
		sum += i;
	return sum/values->Length;
}

C’est pareil, en plus moche. On utilise « ... » au lieu de « params« , et l’appelant peut passer un tableau ou une liste d’arguments :

var parameters = new int[]{45, 68, 97, 45};
CppCliLibrary.average(parameters)
// ou bien
CppCliLibrary.average(45, 68, 97, 45)

Notez que l’interopérabilité entre C# et C++/CLI est native : les deux langages sont managés.

Et en C++ pas CLI, qu’est-ce que donnent les fonctions à nombre variable d’arguments ?

Bah c’est encore plus moche, et plus contraignant. Rappelez-vous :

extern "C" __declspec(dllexport) double average(int n, ...)
{
	double sum = 0;
	va_list args;
	va_start(args, n);
	for(int i=0 ;i < n; i++)
		sum += va_arg(args, int);
	va_end(args);
	return sum/n;
}

La principale différence est finalement assez subtile on n’utilise pas explicitement un tableau, mais on fournit un pointeur vers le début de la liste d’arguments. C’est à la méthode de se débrouiller (avec des macros) pour itérer, caster et s’arrêter lorsqu’il le faut. Généralement, un autre paramètre nommé de la méthode contient les infos nécessaires à cette opération. Dans l’exemple précédent, « n » est utilisé pour passer directement le nombre d’arguments de la liste. Dans printf, c’est la format string qui permet à la fonction de savoir combien d’arguments elle doit lire.

La question rigolote, puisque nous sommes dans le contexte d’un exemple rigolo, est la suivante :

Mais comment appeler les fonctions natives de ce genre depuis C# ? En utilisant pinvoke, probablement, mais plus précisément ?

Réponse : En pleurant. On est obligé de déclarer explicitement les imports pour chacune des utilisations que l’on va faire de la fonction dans notre code managé. En gros :

[DllImport ("NativeLibrary.dll")]
public static extern double average (int n, int i1);

[DllImport ("NativeLibrary.dll")]
public static extern double average (int n, int i1, int i2);

[DllImport ("NativeLibrary.dll")]
public static extern double average (int n, int i1, int i2, int i3);

[DllImport ("NativeLibrary.dll")]
public static extern double average (int n, int i1, int i2, int i3, int i4);

// Etc.

What a PITA, comme qui dirait… Mais c’est ici que l’ornithorynque nous sauve la vie. Car on peut écrire :

[DllImport ("NativeLibrary.dll", CallingConvention = CallingConvention.Cdecl)]
public static extern double average (int n, __arglist );

Et appeler la fonction ainsi :

NativeWrapper.average (4, __arglist (45, 68, 97, 45))

Hourra, donc. Mais quel est ce mot clé bizarre, __arglist, qui n’est même pas reconnu par Resharper ? Et bien il s’agit d’un des mots clés non documentés du langage, qui permettent principalement de jouer avec les TypedReference. Pour mieux comprendre ce qui se passe, essayons de réécrire en C# la méthode Average, sans utiliser le mot clé params, et en se reposant donc uniquement sur les « références typées ». On s’attaquera ensuite à la définition.

public class ManagedEvil
{
    public static double Average(__arglist)
    {
        double sum = 0;
        int count = 0;
        var iterator = new ArgIterator(__arglist);
        do
        {
            TypedReference typedReference = iterator.GetNextArg();
            sum += __refvalue( typedReference,int);
            count++;
        } while (iterator.GetRemainingCount() > 0);
        return sum / count;
    }
}

On note :

• L’apparition du type ArgIterator, dont on crée une instance à partir de la liste d’arguments.
• L’élément courant retourné par l’itérateur est une référence typée : TypedReference.
• Un nouveau mot clé, __refvalue, permet d’extraire la valeur pointée par la référence.

Et tout ça compile, tout ça fonctionne, même si l’intérêt est limité.

TypedReference, __makeref, __refvalue, __reftype

Arrêtons les expériences pour décortiquer un peu plus sérieusement ce TypedReference. La MSDN définit très clairement la TypedReference :

Describes objects that contain both a managed pointer to a location and a runtime representation of the type that may be stored at that location.

Retenons qu’il s’agit d’une structure contenant :

• Un pointeur managé vers un espace mémoire
• Le type de ce qui est pointé en mémoire

Le meilleur endroit pour trouver des infos au sujet de TypedReference est finalement la spécification ECMA 335 du CIL. Je vous laisse fouiller, mais sachez que les bases sont notamment posées dans le paragraphe suivant (cf. 8.6.1.3):

La signature d’une référence typée est en fait représentée en tant que type valeur de base, comme les entiers ou nombres à virgule flottante. Dans la bibliothèque de classes du framework, le type est représenté par System.TypedReference, tandis que dans le langage intermédiaire il est désigné par le mot clé typedref. Ce type doit uniquement être utilisé pour les paramètres et les variables locales. Il ne peut ni être boxé ni être utilisé pour typer un champ, un élément de tableau, ou une valeur de retour de fonction.

Pour que je ne puisse jamais justifier l’intérêt de cet article, les gens chez Microsoft ont bien fait attention à exposer ce type le moins possible. Il est pourtant assez utilisé en interne, notamment dans System.Array, System.Threading.Interlocked, les services d’intérop (InteropServices) ainsi que dans certains overloads cachés utilisant les varargs (String.Concat, Console.WriteLine). A vrai dire, il semblerait que la raison officielle de son existence soit justement le support par le CLR des listes d’arguments, comme nous l’avons vu plus tôt. Il existe cependant un autre endroit (parmi d’autres) où son utilisation peut s’avérer intéressante : la réflexion via les FieldInfo. Mais avant d’y venir, regardons plutôt comment utiliser, très mécaniquement, TypedReference. On peut soit utiliser les mots clés interdits, soit – lorsque c’est possible – utiliser les quelques méthodes statiques de la classe TypedReference elle-même.

Création d’une référence typée : __makeref

Les références typées peuvent être obtenues pour des variables de n’importe quel type (référence ou valeur) à l’aide du mot clé __makeref.

int i = 42;
TypedReference typedReference = __makeref (i);

Ce mot clé dont l’usage n’est pas documenté correspond à l’instruction mkrefany en CIL. Le code intermédiaire correspondant à l’exemple précédant est le suivant :

int i = 42;

L_0000: ldc.i4.s 0x2a	/* push sur la pile d'un int32 = 42						*/
L_0002: stloc.0			/* sauvegarde dans la variable locale i					*/

TypedReference typedReference = __makeref(i);

L_0003: ldloca.s i		/* push sur la pile de l'adresse de i					*/
L_0005: mkrefany int32	/* push sur la pile de la référence typée				*/
L_000a: stloc.1			/* sauvegarde dans la variable locale typedReference	*/

La méthode statique TypedReference.MakeTypedReference permet aussi de créer des références typées, mais pas directement à partir d’une variable. Nous verrons un exemple d’utilisation dans la dernière partie de l’article.

Récupérer et/ou modifier la valeur : __refvalue

Une fois qu’on a une référence typée, il est possible de lire et/ou d’écrire la valeur référencée en utilisant le mot clé __refvalue. Il est visuellement assimilable à un appel de fonction à deux paramètres, dont le premier serait la TypedReference, et le second le type de la valeur référencée. En l’utilisant à droite d’une affectation, on lit la valeur, et en l’utilisant à gauche d’une affectation, on écrit la valeur. Assez troublant…

int i = 42;
TypedReference typedReference = __makeref(i);
int j = __refvalue (typedReference, int);
__refvalue (typedReference, int) = 24;

Encore une fois, il est possible de mapper son utilisation avec un opcode spécifique, refanyval :

int i = 42;
TypedReference typedReference = __makeref(i);

L_0000: ldc.i4.s 0x2a	/* push sur la pile d'un int32 = 42						*/
L_0002: stloc.0			/* sauvegarde dans la variable locale i					*/
L_0003: ldloca.s i		/* push sur la pile de l'adresse de i					*/
L_0005: mkrefany int32	/* push sur la pile de la référence typée				*/
L_000a: stloc.1			/* sauvegarde dans la variable locale typedReference	*/

int j = __refvalue (typedReference, int);

L_000b: ldloc.1			/* push sur la pile de la typedReference				*/
L_000c: refanyval int32 /* push sur la pile de l'adresse de la référence        */
L_0011: ldind.i4		/* déréférencement et push sur la pile de la valeur		*/
L_0012: stloc.2			/* sauvegarde dans la variable locale j					*/

__refvalue (typedReference, int) = 24;

L_0013: ldloc.1			/* push sur la pile de la typedReference				*/
L_0014: refanyval int32 /* push sur la pile de l'adresse de la référence        */ 
L_0019: ldc.i4.s 0x18	/* push sur la pile d'un int32 = 24						*/
L_001b: stind.i4		/* sauvegarde de la valeur à l'adresse de la référence  */

La méthode TypedReference.ToObject permet aussi de déréférencer la TypedReference et d’obtenir sa valeur, boxée.

Récupérer le type : __reftype

Enfin, il est possible de récupérer l’information de type associée à la TypeReference, en utilisant un dernier mot clé __reftype.

int i = 42;
TypedReference typedReference = __makeref(i);
Type type = __reftype(typedReference);

Là encore, on peut faire correspondre __reftype à l’opcode refanytype :

int i = 42;
TypedReference typedReference = __makeref(i);

L_0000: ldc.i4.s 0x2a	/* push sur la pile d'un int32 = 42						*/
L_0002: stloc.0			/* sauvegarde dans la variable locale i					*/
L_0003: ldloca.s i		/* push sur la pile de l'adresse de i					*/
L_0005: mkrefany int32	/* push sur la pile de la référence typée				*/
L_000a: stloc.1			/* sauvegarde dans la variable locale typedReference	*/

Type type = __reftype(typedReference);

L_000b: ldloc.1			/* push sur la pile de la typedReference				*/
L_000c: refanytype		/* push sur la pile du type token de la référence		*/
L_000e: call class Type::GetTypeFromHandle(RuntimeTypeHandle)
L_0013: stloc.2			/* récupération et sauvegarde du Type à partir du token */

Notons que la méthode statique TypedReference.GetTargetType est l’équivalent autorisé de __reftype, et qu’il existe aussi la méthode TypedReference.TargetTypeToken qui retourne le handle du type sous la forme d’un RuntimeTypeHandle. La version light, en somme.

Rien de très impressionnant ; d’ailleurs vous pouvez retourner sur youtube car la suite n’est pas mieux. Mais je persiste !

Un autre exemple : GetValueDirect et SetValueDirect

Je vous disais tout à l’heure que j’avais trouvé un exemple d’utilisation dans lequel on pouvait faire intervenir les TypedReference. Il s’agit de la lecture écriture des champs par réflexion, et plus particulièrement des champs de type valeur. Et encore plus particulièrement lorsqu’ils sont imbriqués.

Prenons pour exemple ce modèle simpliste :

public struct Person
{
	public Address Address;
}

public struct Address
{
	public City City;
}

public struct City
{
	public int ZipCode;
}

Il est important de bien noter que Person, Address, City et ZipCode sont des value types. Si on veut inspecter une instance de Person par réflexion, jusqu’à lire le ZipCode de son adresse, on va écrire quelque chose comme :

// On a une instance de Person
var p = new Person();
p.Address.City.ZipCode = 75000;

// On récupère les FieldInfo
var addressField = typeof(Person).GetField("Address");
var cityField = typeof(Address).GetField("City");
var zipCodeField = typeof(City).GetField("ZipCode");

// On chaine les appels à FieldInfo.GetValue pour inspecter la Person
// et lire la valeur du ZipCode
var zipCode =  (int)zipCodeField.GetValue(cityField.GetValue(addressField.GetValue(p)));

Ca fonctionne, mais le boxing a tué mon hourra. GetValue prend un object en argument, et retourne un object, alors qu’on travaille ici sur des types valeurs… En lisant la dernière ligne de droite à gauche :

• p va être boxé pour être passé en paramètre à GetValue
• addressField.GetValue va boxer la valeur du champ Address pour le retourner sous la forme d’un object
• cityField.GetValue va boxer la valeur du champ City pour le retourner sous la forme d’un object
• zipCodeField.GetValue va boxer la valeur du champ ZipCode pour le retourner sous la forme d’un object
• Le cast en int effectue l’ultime et nécessaire unboxing

Pas terrible…

Heureusement, il existe sur FieldInfo la méthode GetValueDirect, qui prend en paramètre une TypedReference !

Si on peut directement récupérer une référence typée sur le ZipCode, on peut éviter quelques emboitages :

var p = new Person();
p.Address.City.ZipCode = 75000;
FieldInfo zipCodeField = typeof(City).GetField("ZipCode");
var zipCode = (int)zipCodeField.GetValueDirect(__makeref (p.Address.City)); 

Seulement, on change les contraintes, car la création de la référence typée de cette façon implique alors que l’on connaisse Address et City au design time. Qu’à cela ne tienne : il existe la méthode statique TypedReference.MakeTypedReference évoquée plus tôt, qui permet de construire une référence typée à partir d’une target et d’un tableau de FieldInfo correspondant à l’inspection désirée de l’espace mémoire réservé par p :

var p = new Person ();
p.Address.City.ZipCode = 75000;
var addressField = typeof (Person).GetField ("Address");
var cityField = typeof (Address).GetField ("City");
var zipCodeField = typeof (City).GetField ("ZipCode");

TypedReference r = TypedReference.MakeTypedReference (p, new[] {addressField, cityField});
var zipCode = (int) zipCodeField.GetValueDirect (r);

Dans ce cas précis, les performances mesurées sont environ 4 fois meilleures en utilisant GetValueDirect à la place de GetValue. Hourra.

Quant à l’écriture, nous n’avons même pas le luxe du choix, puisque chainer les SetValue ne peut en aucun cas modifier la personne, cette fonction retournant à chaque fois une copie des valeurs… Il faut donc nécessairement utiliser SetValueDirect et une TypedReference.

Conclusion

La conclusion, que je vous dois brève :

Ce qui n’est pas documenté ne doit pas être utilisé. En gros, tout ce qui est lié aux arglists est à oublier. En revanche, la création et la manipulation de TypedReference sans passer par tous les __mots __clés __moches n’est pas réprouvée. Notez simplement que TypedReference n’est pas CLS Compliant.

]]> https://codingly.com/2009/01/15/si-les-types-etaient-des-animaux-typedreference-serait-un-ornithorynque/feed/ 7 Romain