Reflektierende Parameternamen: Missbrauch von C#-Lambda-Ausdrücken oder brillante Syntax?

Question

Ich betrachte die MvcContrib Grid-Komponente und ich bin fasziniert und gleichzeitig abgestoßen von einem syntaktischen Trick, der in der Gittersyntax :

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

Die obige Syntax setzt das style-Attribut des generierten HTML auf width:100% . Wenn Sie genau hinschauen, ist "Stil" nirgends angegeben. Er wird abgeleitet aus dem Name des Parameters im Ausdruck! Ich musste nachforschen und fand heraus, wo die "Magie" passiert:

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

Der Code verwendet also in der Tat den formalen Namen der Parameter zur Kompilierungszeit, um das Wörterbuch der Attribut-Name-Wert-Paare zu erstellen. Das daraus resultierende Syntaxkonstrukt ist in der Tat sehr ausdrucksstark, aber gleichzeitig auch sehr gefährlich.

Die allgemeine Verwendung von Lambda-Ausdrücken ermöglicht die Ersetzung der Namen ohne Nebenwirkung verwendet werden. Ich sehe ein Beispiel in einem Buch, das sagt collection.ForEach(book => Fire.Burn(book)) Ich weiß, dass ich in meinen Code schreiben kann collection.ForEach(log => Fire.Burn(log)) y es bedeutet dasselbe . Aber mit der MvcContrib Grid-Syntax finde ich plötzlich Code, der aktiv nach den Namen sucht und Entscheidungen trifft, die ich für meine Variablen wähle!

Also ist dies gängige Praxis mit der C# 3.5/4.0-Gemeinschaft und die Lambda-Ausdrücke Liebhaber? Oder handelt es sich um einen abtrünnigen Außenseiter, über den ich mir keine Sorgen machen sollte?

Answer 1

Ich finde das merkwürdig, nicht so sehr wegen der Name sondern weil die lambda ist unnötig ; es könnte einen anonymen Typ verwenden und flexibler sein:

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

Dieses Muster wird zum Beispiel in ASP.NET MVC verwendet, und hat andere Anwendungen (a caveat beachten Sie auch Gedanken von Ayende wenn der Name ein magischer Wert und nicht aufruferspezifisch ist)

Answer 2

Die Interoperabilität ist schlecht. Betrachten Sie zum Beispiel dieses C# - F# Beispiel

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

Ergebnis:

"arg" wird gedruckt (nicht "yadda").

Infolgedessen sollten Bibliotheksentwickler entweder diese Art von "Missbrauch" vermeiden oder zumindest eine "Standard"-Überladung (z. B. die den Stringnamen als zusätzlichen Parameter annimmt) bereitstellen, wenn sie eine gute Interoperabilität zwischen den .Net-Sprachen erreichen wollen.

Answer 3

Ich wollte nur meine Meinung dazu sagen (ich bin der Autor der Grid-Komponente MvcContrib).

Das ist eindeutig Sprachmissbrauch - daran besteht kein Zweifel. Allerdings würde ich es nicht wirklich als kontraintuitiv betrachten - wenn Sie sich einen Aufruf von Attributes(style => "width:100%", @class => "foo")
Ich denke, es ist ziemlich offensichtlich, was hier vor sich geht (es ist sicherlich nicht schlimmer als der anonyme Ansatz). Von einem intellisense Perspektive, ich stimme es ist ziemlich undurchsichtig.

Für diejenigen, die es interessiert, einige Hintergrundinformationen über die Verwendung in MvcContrib...

Ich fügte dies in das Raster als eine persönliche Vorliebe - Ich mag nicht die Verwendung von anonymen Typen als Wörterbücher (mit einem Parameter, der "Objekt" nimmt ist genauso undurchsichtig wie eine, die Parameter Func[] nimmt) und die Dictionary-Auflistung Initialisierer ist ziemlich wortreich (ich bin auch kein Fan von wortreichen fließenden Schnittstellen, z. B. mit mehreren Aufrufen zu einem Attribut("style", "display:none").Attribut("class", "foo") usw. zu verketten)

Wenn C# eine weniger ausführliche Syntax für Wörterbuchliterale hätte, dann hätte ich mir nicht die Mühe gemacht, diese Syntax in die Gitterkomponente einzubauen :)

Ich möchte auch darauf hinweisen, dass die Verwendung dieser in MvcContrib ist völlig optional - diese sind Erweiterung Methoden, die Überladungen, die ein IDictionary stattdessen nehmen wrap. Ich denke, es ist wichtig, dass Sie, wenn Sie eine Methode wie diese bereitstellen, auch einen "normaleren" Ansatz unterstützen sollten, z. B. für Interop mit anderen Sprachen.

Außerdem erwähnte jemand den "Reflexions-Overhead", und ich wollte nur darauf hinweisen, dass es bei diesem Ansatz wirklich keinen großen Overhead gibt - es ist keine Reflexion zur Laufzeit oder Ausdruckskompilierung beteiligt (siehe http://blog.bittercoder.com/PermaLink,guid,206e64d1-29ae-4362-874b-83f5b103727f.aspx ).

Answer 4

Ich würde bevorzugen

Attributes.Add(string name, string value);

Es ist viel eindeutiger und standardisiert, und durch die Verwendung von Lambdas wird nichts gewonnen.

Answer 5

Willkommen im Rails Land :)

Daran ist wirklich nichts auszusetzen, solange man weiß, was vor sich geht. (Problematisch wird es dann, wenn diese Dinge nicht gut dokumentiert sind).

Die Gesamtheit des Rails-Frameworks basiert auf der Idee, dass Konvention vor Konfiguration geht. Wenn man Dinge auf eine bestimmte Art und Weise benennt, wird man in eine Konvention eingebunden, die sie verwenden, und man erhält eine ganze Menge Funktionalität umsonst. Wenn man die Namenskonvention befolgt, kommt man schneller ans Ziel. Das Ganze funktioniert brillant.

Ein weiterer Ort, an dem ich einen solchen Trick gesehen habe, sind Methodenaufruf-Assertions in Moq. Sie übergeben ein Lambda, aber das Lambda wird nie ausgeführt. Sie verwenden den Ausdruck nur, um sicherzustellen, dass der Methodenaufruf erfolgt ist, und lösen andernfalls eine Ausnahme aus.