Reflecting parameter name : abus des expressions lambda de C# ou brillance de la syntaxe ?

Question

Je regarde le MvcContrib Je suis fasciné, et en même temps dégoûté, par une astuce syntaxique utilisée dans le composant de la grille. Syntaxe de la grille :

.Attributes(style => "width:100%")

La syntaxe ci-dessus donne à l'attribut style du HTML généré la valeur suivante width:100% . Si vous faites attention, le "style" n'est spécifié nulle part. Il est déduit du nom du paramètre dans l'expression ! J'ai dû creuser cette question et j'ai trouvé où la "magie" se produit :

Hash(params Func<object, TValue>[] hash)
{
    foreach (var func in hash)
    {
        Add(func.Method.GetParameters()[0].Name, func(null));
    }
}

Donc, en effet, le code utilise le nom formel, au moment de la compilation, des paramètres pour créer le dictionnaire des paires nom-valeur des attributs. La construction syntaxique qui en résulte est en effet très expressive, mais en même temps très dangereuse.

L'utilisation générale des expressions lambda permet de remplacer l'expression noms utilisé sans effet secondaire. Je vois un exemple dans un livre qui dit collection.ForEach(book => Fire.Burn(book)) Je sais que je peux écrire dans mon code collection.ForEach(log => Fire.Burn(log)) et cela signifie la même chose . Mais avec la syntaxe de la grille MvcContrib, tout d'un coup, je trouve du code qui regarde activement et prend des décisions basées sur les noms que je choisis pour mes variables !

S'agit-il d'une pratique courante au sein de la communauté C# 3.5/4.0 et des amateurs d'expressions lambda ? Ou s'agit-il d'un cas isolé dont je ne devrais pas m'inquiéter ?

Answer 1

Je trouve ça étrange, pas tant à cause de la nom mais parce que le lambda est inutile il pourrait utiliser un type d'anonymat et être plus souple :

.Attributes(new { style = "width:100%", @class="foo", blip=123 });

Il s'agit d'un modèle utilisé dans une grande partie d'ASP.NET MVC (par exemple), et a autres usages (a avertissement , notez également Les pensées d'Ayende si le nom est une valeur magique plutôt que spécifique à l'appelant)

Answer 2

L'interopérabilité est faible. Par exemple, considérez cet exemple C# - F#

C# :

public class Class1
{
    public static void Foo(Func<object, string> f)
    {
        Console.WriteLine(f.Method.GetParameters()[0].Name);
    }
}

F# :

Class1.Foo(fun yadda -> "hello")

Résultat :

"arg" est imprimé (et non "yadda").

Par conséquent, les concepteurs de bibliothèques devraient soit éviter ce genre d'"abus", soit au moins fournir une surcharge "standard" (par exemple, qui prend le nom de la chaîne comme paramètre supplémentaire) s'ils veulent avoir une bonne interopérabilité entre les langages .Net.

Answer 3

Je voulais juste donner mon avis (je suis l'auteur du composant de grille MvcContrib).

Il s'agit d'un abus de langage, sans aucun doute. Cependant, je ne considérerais pas vraiment cela comme étant contre intuitif - lorsque vous regardez un appel à Attributes(style => "width:100%", @class => "foo")
Je pense que ce qui se passe est assez évident (ce n'est certainement pas pire que l'approche de type anonyme). D'un point de vue intellisense, je suis d'accord pour dire que c'est assez opaque.

Pour ceux qui sont intéressés, quelques informations de base sur son utilisation dans MvcContrib...

J'ai ajouté ceci à la grille par préférence personnelle - je n'aime pas l'utilisation de types anonymes comme dictionnaires (avoir un paramètre qui prend "object" est tout aussi opaque que celui qui prend des paramètres Func[]) et l'initialisateur de collection Dictionary est plutôt verbeux (je ne suis pas non plus un fan des interfaces fluides verbeuses, par exemple devoir enchaîner plusieurs appels à un Attribute("style", "display:none").Attribute("class", "foo") etc)

Si le C# avait une syntaxe moins verbeuse pour les littéraux de dictionnaire, je n'aurais pas pris la peine d'inclure cette syntaxe dans le composant de grille :)

Je veux aussi souligner que l'utilisation de ceci dans MvcContrib est complètement optionnelle - ce sont des méthodes d'extension qui enveloppent les surcharges qui prennent un IDictionary à la place. Je pense qu'il est important que si vous fournissez une méthode comme celle-ci, vous devriez également prendre en charge une approche plus "normale", par exemple pour l'interopérabilité avec d'autres langages.

De plus, quelqu'un a mentionné la "surcharge de réflexion" et je voulais juste souligner qu'il n'y a pas vraiment de surcharge avec cette approche - il n'y a pas de réflexion à l'exécution ou de compilation d'expression impliquée (voir http://blog.bittercoder.com/PermaLink,guid,206e64d1-29ae-4362-874b-83f5b103727f.aspx ).

Answer 4

Je préférerais

Attributes.Add(string name, string value);

C'est beaucoup plus explicite et standard et on ne gagne rien à utiliser des lambdas.

Answer 5

Bienvenue à Rails Land :)

Il n'y a vraiment rien de mal à cela, tant que vous savez ce qui se passe. (C'est lorsque ce genre de choses n'est pas bien documenté qu'il y a un problème).

L'intégralité du framework Rails est construite sur l'idée de la convention par rapport à la configuration. Nommer les choses d'une certaine manière vous permet d'adhérer à une convention qu'ils utilisent et vous obtenez un grand nombre de fonctionnalités gratuitement. Suivre la convention de nommage vous permet d'atteindre votre objectif plus rapidement. L'ensemble fonctionne brillamment.

Un autre endroit où j'ai vu une astuce comme celle-ci est dans les assertions d'appel de méthode dans Moq. Vous passez un lambda, mais celui-ci n'est jamais exécuté. Ils utilisent simplement l'expression pour s'assurer que l'appel de méthode s'est produit et lancent une exception dans le cas contraire.