Nome del parametro riflettente: abuso delle espressioni lambda C # o brillantezza della sintassi?

Sto guardando il componente MvcContrib Grid e sono affascinato, ma allo stesso tempo respinto, da un trucco sintattico usato nella sintassi Grid :

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

La sintassi sopra imposta l'attributo di stile dell'HTML generato su width:100%. Ora, se presti attenzione, lo "stile" non è specificato da nessuna parte. Viene dedotto dal nome del parametro nell'espressione! Ho dovuto scavare in questo e ho scoperto dove accade la 'magia':

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

Quindi, in effetti, il codice utilizza il tempo formale di compilazione, il nome dei parametri per creare il dizionario delle coppie nome-valore dell'attributo. Il costrutto della sintassi risultante è davvero molto espressivo, ma allo stesso tempo molto pericoloso.

L'uso generale delle espressioni lambda consente la sostituzione dei nomi utilizzati senza effetti collaterali. Vedo un esempio in un libro che dice collection.ForEach(book => Fire.Burn(book))che so di poter scrivere nel mio codice collection.ForEach(log => Fire.Burn(log))e significa la stessa cosa . Ma con la sintassi della griglia MvcContrib qui all'improvviso, trovo codice che cerca attivamente e prende decisioni in base ai nomi che scelgo per le mie variabili!

Quindi è questa pratica comune con la comunità C # 3.5 / 4.0 e gli amanti delle espressioni lambda? O un ladro è un truffatore di cui non dovrei preoccuparmi?

Ciò ha scarsa interoperabilità. Ad esempio, considera questo esempio 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")

Risultato:

Viene stampato "arg" (non "yadda").

Di conseguenza, i progettisti di biblioteche dovrebbero evitare questo tipo di "abusi", o almeno fornire un sovraccarico "standard" (ad es. Che prende il nome della stringa come parametro extra) se vogliono avere una buona interoperabilità tra i linguaggi .Net.

Lo trovo strano non tanto per il nome , ma perché la lambda non è necessaria ; potrebbe usare un tipo anonimo ed essere più flessibile:

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

Questo è un modello usato in gran parte di ASP.NET MVC (per esempio) e ha altri usi (un avvertimento , nota anche i pensieri di Ayende se il nome è un valore magico piuttosto che specifico del chiamante)

Volevo solo lanciarmi secondo me (sono l'autore del componente griglia MvcContrib).

Questo è sicuramente un abuso di lingua - non c'è che dire. Tuttavia, non lo considererei davvero intuitivo - quando guardi una chiamata Attributes(style => "width:100%", @class => "foo")
penso che sia abbastanza ovvio cosa sta succedendo (Non è certamente peggio dell'approccio di tipo anonimo). Dal punto di vista intellettuale, sono d'accordo che è piuttosto opaco.

Per gli interessati, alcune informazioni di base sul suo utilizzo in MvcContrib ...

Ho aggiunto questo alla griglia come preferenza personale - non mi piace l'uso di tipi anonimi come dizionari (avere un parametro che accetta "oggetto" è opaco quanto uno che accetta parametri Func []) e l'inizializzatore della raccolta Dizionario è piuttosto prolisso (non sono anche un fan delle interfacce fluide verbose, ad esempio dover unire più chiamate a un attributo ("stile", "display: nessuno"). Attributo ("classe", "pippo") ecc.)

Se C # avesse una sintassi meno dettagliata per i letterali del dizionario, non mi sarei preso la briga di includere questa sintassi nel componente griglia :)

Voglio anche sottolineare che l'uso di questo in MvcContrib è completamente facoltativo: si tratta di metodi di estensione che avvolgono sovraccarichi che richiedono invece un IDictionary. Penso che sia importante che se fornisci un metodo come questo, dovresti anche supportare un approccio più "normale", ad esempio per l'interoperabilità con altre lingue.

Inoltre, qualcuno ha menzionato il "sovraccarico di riflessione" e volevo solo sottolineare che in questo approccio non esiste davvero un sovraccarico: non è necessaria alcuna riflessione di runtime o compilazione di espressioni (vedere http://blog.bittercoder.com /PermaLink,guid.206e64d1-29ae-4362-874b-83f5b103727f.aspx ).

preferirei

Attributes.Add(string name, string value);

È molto più esplicito e standard e non si ottiene nulla usando lambda.

Benvenuto in Rails Land :)

Non c'è davvero niente di sbagliato fintanto che sai cosa sta succedendo. (È quando questo genere di cose non è ben documentato che c'è un problema).

L'intero framework Rails si basa sull'idea della convenzione sulla configurazione. Denominare le cose in un certo modo ti porta in una convenzione che stanno usando e ottieni molte funzionalità gratuitamente. Seguire la convenzione di denominazione ti porta dove vai più veloce. Il tutto funziona alla perfezione.

Un altro posto in cui ho visto un trucco come questo è nelle asserzioni sulle chiamate di metodo in Moq. Si passa in una lambda, ma la lambda non viene mai eseguita. Usano semplicemente l'espressione per assicurarsi che la chiamata al metodo sia avvenuta e, in caso contrario, generare un'eccezione.

Questo è orribile su più di un livello. E no, questo non è niente come Ruby. È un abuso di C # e .NET.

Ci sono stati molti suggerimenti su come farlo in un modo più semplice: tuple, tipi anonimi, un'interfaccia fluida e così via.

Ciò che lo rende così cattivo è che è solo il modo di cercare il proprio bene:

• Cosa succede quando è necessario chiamare questo da Visual Basic?

  .Attributes(Function(style) "width:100%")

• È completamente intuitivo e intellisense fornirà poco aiuto per capire come passare le cose.

• È inutilmente inefficiente.

• Nessuno avrà idea di come mantenerlo.

• Qual è il tipo di argomento che va agli attributi? è Func<object,string>? In che modo rivela questa intenzione? Qual è la tua documentazione intellisense che dice "Per favore ignora tutti i valori dell'oggetto"?

Penso che tu sia completamente giustificato avere quei sentimenti di repulsione.

Sono nel campo "Sintassi brillantezza", se lo documentano chiaramente, e sembra così figo, non c'è quasi nessun problema con esso!

Entrambi. È abusaggio delle espressioni lambda E brillantezza della sintassi.

Quasi mai mi sono imbattuto in questo tipo di utilizzo. Penso che sia "inappropriato" :)

Questo non è un modo di utilizzo comune, è incompatibile con le convenzioni generali. Questo tipo di sintassi presenta ovviamente vantaggi e svantaggi:

Contro

• Il codice non è intuitivo (le convenzioni usuali sono diverse)
• Tende ad essere fragile (la ridenominazione del parametro interromperà la funzionalità).
• È un po 'più difficile da testare (falsificare l'API richiederà l'uso della riflessione nei test).
• Se l'espressione viene usata intensamente, sarà più lenta a causa della necessità di analizzare il parametro e non solo il valore (costo di riflessione)

Professionisti

• È più leggibile dopo che lo sviluppatore si è adattato a questa sintassi.

In conclusione : nella progettazione dell'API pubblica avrei scelto un modo più esplicito.

No, non è certamente una pratica comune. È controintuitivo, non c'è modo di guardare semplicemente il codice per capire cosa fa. Devi sapere come viene utilizzato per capire come viene utilizzato.

Invece di fornire attributi usando una matrice di delegati, i metodi di concatenamento sarebbero più chiari e avrebbero prestazioni migliori:

.Attribute("style", "width:100%;").Attribute("class", "test")

Anche se questo è un po 'più da scrivere, è chiaro e intuitivo.

Posso usare questo per coniare una frase?

magic lambda (n): una funzione lambda utilizzata esclusivamente allo scopo di sostituire una stringa magica.

Cosa c'è di sbagliato in quanto segue:

html.Attributes["style"] = "width:100%";

Tutta questa sfuriata sull'orrore è un gruppo di ragazzi di lunga data che reagiscono in modo eccessivo (e io sono un programmatore di lunga data di C # e ancora un grande fan del linguaggio). Non c'è nulla di orribile in questa sintassi. È semplicemente un tentativo di rendere la sintassi più simile a ciò che stai cercando di esprimere. Meno "rumore" c'è nella sintassi di qualcosa, più facile sarà capire dal programmatore. Ridurre il rumore in una riga di codice aiuta solo un po ', ma lascia che si accumuli su un numero sempre maggiore di codice e si rivela un vantaggio sostanziale.

Questo è un tentativo dell'autore di cercare gli stessi benefici che ti offre DSL: quando il codice "assomiglia" a quello che stai cercando di dire, hai raggiunto un posto magico. Puoi discutere se questo è buono per l'interoperabilità o se è abbastanza più bello dei metodi anonimi per giustificare parte del costo della "complessità". Abbastanza giusto ... quindi nel tuo progetto dovresti fare la scelta giusta se usare questo tipo di sintassi. Ma comunque ... questo è un tentativo intelligente da parte di un programmatore di fare ciò che, alla fine della giornata, stiamo tutti cercando di fare (che ce ne rendiamo conto o meno). E quello che stiamo tutti cercando di fare, è questo: "Di 'al computer cosa vogliamo che faccia in un linguaggio il più vicino possibile a come pensiamo a cosa vogliamo che faccia."

Avvicinarsi all'esprimere le nostre istruzioni ai computer nello stesso modo in cui riteniamo internamente una chiave per rendere il software più gestibile e più accurato.

EDIT: avevo detto "la chiave per rendere il software più gestibile e più accurato", che è un po 'follemente esagerato di unicorno. L'ho cambiato in "una chiave".

Questo è uno dei vantaggi degli alberi delle espressioni: è possibile esaminare il codice stesso per ulteriori informazioni. Ecco come .Where(e => e.Name == "Jamie")può essere convertito nella clausola SQL Where equivalente. Questo è un uso intelligente degli alberi delle espressioni, anche se spero che non vada oltre. Qualcosa di più complesso sarà probabilmente più difficile del codice che spera di sostituire, quindi sospetto che si autolimiterà.

È un approccio interessante. Se hai costretto il lato destro dell'espressione a essere solo costanti, allora puoi implementare usando

Expression<Func<object, string>>

Che penso sia quello che vuoi davvero invece del delegato (stai usando lambda per ottenere nomi di entrambe le parti) Vedi l'implementazione ingenua di seguito:

public static IDictionary<string, string> Hash(params Expression<Func<object, string>>[] hash) {
    Dictionary<string, string> values = new Dictionary<string,string>();
    foreach (var func in hash) {
        values[func.Parameters[0].Name] = ((ConstantExpression)func.Body).Value.ToString();
    }
    return values;
}

Ciò potrebbe anche risolvere il problema dell'interoperabilità linguistica menzionato in precedenza nel thread.

Il codice è molto intelligente, ma potenzialmente causa più problemi che risolve.

Come hai sottolineato, ora c'è un'oscura dipendenza tra il nome del parametro (stile) e un attributo HTML. Non viene eseguito alcun controllo del tempo di compilazione. Se il nome del parametro è errato, la pagina probabilmente non avrà un messaggio di errore di runtime, ma sarà molto più difficile trovare un bug logico (nessun errore, ma comportamento errato).

Una soluzione migliore sarebbe quella di avere un membro di dati che può essere verificato in fase di compilazione. Quindi invece di questo:

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

il codice con una proprietà Style può essere verificato dal compilatore:

.Attributes.Style = "width:100%";

o anche:

.Attributes.Style.Width.Percent = 100;

Questo è più lavoro per gli autori del codice, ma questo approccio sfrutta la forte capacità di controllo del tipo di C #, che aiuta a prevenire che i bug entrino nel codice in primo luogo.

anzi sembra Ruby =), almeno per me l'uso di una risorsa statica per una "ricerca" dinamica successiva non si adatta alle considerazioni di progettazione API, spero che questo trucco intelligente sia facoltativo in quell'API.

Potremmo ereditare da IDictionary (o meno) e fornire un indicizzatore che si comporta come un array php quando non è necessario aggiungere una chiave per impostare un valore. Sarà un uso valido della semantica .net non solo di c #, e avrà ancora bisogno di documentazione.

spero che sia di aiuto

Secondo me è un abuso degli lambda.

Per quanto riguarda la brillantezza della sintassi, trovo style=>"width:100%"chiaramente confuso. Soprattutto a causa del =>invece di=

IMHO, è un bel modo di farlo. Tutti amiamo il fatto che nominare un controller di classe lo renderà un controller in MVC giusto? Quindi ci sono casi in cui la denominazione è importante.

Anche l'intenzione è molto chiara qui. È molto facile capire che .Attribute( book => "something")si tradurrà in book="something"e .Attribute( log => "something")comporteràlog="something"

Immagino che non dovrebbe essere un problema se lo tratti come una convenzione. Sono dell'opinione che qualunque cosa ti faccia scrivere meno codice e rendere evidente l'intenzione è una buona cosa.

Se i nomi dei metodi (func) sono ben scelti, questo è un modo geniale per evitare mal di testa da manutenzione (ad esempio: aggiungere una nuova funzione, ma si è dimenticato di aggiungerla all'elenco di mappatura dei parametri di funzione). Certo, devi documentarlo pesantemente e faresti meglio a generare automaticamente la documentazione per i parametri dalla documentazione per le funzioni in quella classe ...

Penso che questo non sia meglio di "stringhe magiche". Non sono un grande fan dei tipi anonimi neanche per questo. Ha bisogno di un approccio migliore e fortemente tipizzato.