Mais je pense qu’en restant dans un contexte de swicth/case, l’argument de la lisibilité est valable. On parle d’une logique « basique », contrairement à l’exemple de la méthode « IsPrime ».

De la même manière pour un swicth/case un nombre limité de cas, et avec des opérations relativement simple, le « if-is-cast » sera plus facile à comprendre.

Cependant, avec la même construction mais un nombre plus conséquent de cas, et des opération plus complexe pour chacun des cas, ta solution prouve toute son utilité.

Pour moi ça reste une question de contexte dans le code.

Ceci-dit , quit à imaginer des méthodes élegantes, j’aurai je pense tenté de me débarasser du switch et suivre le conseil avisé : « la première chose qu’il vous faut faire est de vous demander si vous avez besoin de faire un switch sur un type[...]« . (on m’objectera qu’en matiere d’ »over design », contourner un switch aboutit parfois a bien pire que la solution présentée :s)

Ce ceci-dit dit, j’avoue que je ne me serais jamais posé la question de savoir comment j’allais éviter un switch (ou assimilé if..elseif, etc.) par « mon propre switch », c’est vraiement une belle solution.

Sinon, sympa le pattern à la fluent, assez lisible, et surtout typé vs. la solution triviale n° 1, merci de l’exemple, à reprendre je pense, vive les méthodes d’extension ;)

…bientôt le dynamic, bientôt.

    int candidate = 12345;
    bool result = true;
    if ((candidate & 1) == 0)
    {
        result = candidate == 2;
    }
    else
    {
        int num = (int)Math.Sqrt(candidate);
        for (int i = 3; i <= num; i += 2)
        {
            if ((candidate % i) == 0)
            {
                result = false;
                break;
            }
        }
    }

Est plus lisible que :

bool result = IsPrime(12345);

Car on n’a pas besoin d’aller voir l’implémentation de la méthode IsPrime, ou de savoir que la méthode IsPrime existe.

Mais je pense pas qu’on puisse t’en vouloir de faire des exemples simples pour comprendre le cœur du sujet :)

L’autre intérêt du switch — et ce n’est pas flagrant dans l’exemple proposé, je vous l’accorde — est qu’il fournit à chaque bloc case, via le paramètre du délégué, une variable du bon type qui peut être utilisée et réutilisée sans cast.

    .Case<MethodCallExpression>(e =>
                                {
                                    // e est une instance de MethodCallExpression
                                    Console.WriteLine(e.Method);
                                    Console.WriteLine(e.Arguments);
                                    // etc.
                                });

Dans le cas où l’on doit manipuler n fois l’expression en tant que MethodCallExpression par exemple, l’utilisation répétée du cast devrait choquer tout le monde.

Quand à la prétendue complexité de cette nouvelle syntaxe, ça me laisse perplexe. On ne doit pas utiliser les lambdas et les generics pour que les membres de CodeS-SourceS puissent nous lire ? Appelez-moi élitiste…

Edit: Switcher sur le NodeType ne fournit pas une variable manipulable du bon type, il faut encore caster derrière. Mais effectivement lorsqu’il est juste nécessaire de déterminer le type de l’expression, c’est la solution évidente.