Come posso pronunciare "= >" come usato nelle espressioni lambda in .Net

https://stackoverflow.com/questions/274022

07-07-2019
|

Domanda

Raramente incontro altri programmatori!

Il mio pensiero quando ho visto il token per la prima volta era " implica che " dato che è quello che lo leggerebbe come in una prova matematica, ma chiaramente non ha senso.

Quindi, come posso dire o leggere " = > " come in: -

IEnumerable<Person> Adults = people.Where(p => p.Age > 16)

O c'è anche un modo concordato per dirlo?

Soluzione

Di solito dico "tale che" quando leggo quell'operatore.

Nel tuo esempio, p = > p.Age > 16 recita come "P, tale che p.Age è maggiore di 16."

In realtà, ho posto questa domanda sui forum pre-release ufficiali di linq e Anders Hejlsberg ha risposto dicendo

Di solito leggo il = > operatore come " diventa " o " per cui " ;. Ad esempio,
  Func f = x = > x * 2;
  Func test = c = > c.City == " London " ;;
  legge come " x diventa x * 2 " e "c" per cui c.City equivale a Londra "

Per quanto riguarda 'va a', non ha mai avuto senso per me. "p" non sta andando da nessuna parte.

Nel caso di leggere il codice a qualcuno, diciamo, per telefono, quindi fintanto che sono colleghi programmatori C #, userò semplicemente la parola "lambda" - vale a dire " p lambda p dot età superiore a sedici anni. "

Nei commenti Steve Jessop ha menzionato "mappe a" in caso di trasformazioni - prendendo così l'esempio di Anders:

x => x * 2;

leggerebbe

x mappa a x volte 2.

Ciò sembra molto più vicino all'intenzione reale del codice che "diventa" per questo caso.

Altri suggerimenti

Da MSDN :

Tutte le espressioni lambda usano lambda operator = > ;, che viene letto come " va ".

Lettura del codice sul Telefono

Da Eric Lippert:

Personalmente direi c = > c + 1 come "vedi vai a vedere più uno". Alcune varianti che ho sentito:

Per una proiezione, (Cliente c) = > c.Name: " cliente vedi diventa vedi punto nome "

Per un predicato, (Cliente c) = > c.Age > 21: "i clienti vedono tali che vedere l'età dei punti è maggiore di ventuno"

L'ho sempre chiamato l'operatore " wang " : -)

"p wang età di p maggiore di 16"

Ho visto gente dire, " Arrow. "

Uso " va in " perché un libro LINQ mi ha detto di :)

Che ne dici di " mappe su " ;? È al tempo stesso succinto e probabilmente tecnicamente più accurato (cioè nessun suggerimento di un cambiamento di stato come con "va a" o "diventa", nessuna conflazione di un insieme con la sua funzione caratteristica come con "tale che" tale o "per cui" ;) rispetto alle altre alternative. Sebbene se c'è già uno standard come sembra implicare la pagina MSDN, forse dovresti semplicemente andare con quello (almeno per il codice C #).

" Mappe su " è la mia pronuncia preferita. Matematicamente parlando, una funzione "mappe" i suoi argomenti al suo valore di ritorno (si potrebbe persino chiamare la funzione "mappatura"), quindi per me ha senso usare questa terminologia nella programmazione, in particolare perché la programmazione funzionale (specialmente il calcolo lambda) è molto vicina alla matematica. È anche più neutrale di "diventa", "va", ecc., Poiché non suggerisce un cambio di stato, come menzionato nel contesto.

Non ci ho pensato molto, ma dico per caso " a " ;. È breve e conciso e implica che la variabile viene passata a nell'espressione. Suppongo che potrebbe essere confuso con il numero 2 ("due"), ma tendo a pronunciare "a" più simile a "quot" ta " quando si parla. Nessuno (che conosce almeno i lambda) mi ha mai detto che lo ritenevano ambiguo ...

// "Func f equals x to x times two"
Func f = x=> x * 2;

// "Func test equals c to c dot City equals London"
Func test = c => c.City == "London"

La mia breve risposta: " c 'lambda-of' e " ;. Anche se mi sto aggrappando a "lambda" c "funzione" e ", penso che lambda-of sia il compromesso ecumenico. Segue l'analisi.

Questa è un'ottima domanda se non altro per le risposte bizzarre. La maggior parte delle traduzioni ha altri significati rispetto alle espressioni lambda, portando a interpretazioni esotiche. Come vecchio hacker di espressioni lambda, ignoro semplicemente la notazione .NET e la riscrivo come lambda nella mia testa, desiderando che avessero fatto quasi tutto il resto per questo.

Per narrare il codice al telefono, vuoi che qualcuno sia in grado di scrivere il codice in sequenza. Questo è un problema, ovviamente, ma lambda-freccia o qualcosa è probabilmente il migliore che puoi ottenere, o forse lambda-in, ma lambda-of è il più preciso.

Il problema è l'uso dell'infisso e come nominare l'intera cosa e il ruolo delle parti sinistra e destra con qualcosa che funziona quando si parla nel posto infix.

Questo potrebbe essere un problema troppo limitato!

Non userei " tale che " perché ciò implica che il lato destro è un predicato che il lato sinistro dovrebbe soddisfare. Questo è molto diverso dal parlare di un lato destro da cui il lato sinistro è stato sottratto come parametro funzionale. (L'affermazione MSDN su " Tutte le espressioni lambda " è semplicemente offensiva e inaccurata.)

Qualcosa si classifica su " va su " anche se potrebbe essere il più vicino possibile. " Vai a " implica una trasformazione, ma non esiste esattamente una variabile c che vada a un'espressione in c. L'astrazione per una funzione è un po 'sfuggente. Potrei abituarmi a questo, ma desidero ancora qualcosa che enfatizzi l'astrazione della variabile.

Dato che il lato sinistro è sempre un semplice identificatore nei casi utilizzati finora [ma attendo estensioni che potrebbero confonderlo in seguito], penso a " c = > espressione " Vorrei leggere " c 'funzione lambda' espressione " ' o persino "c" arg "" funzione "espressione". Nell'ultimo caso, potrei quindi dire cose come " b 'arg' c 'arg' 'funzione' espressione " ;.

Potrebbe essere meglio rendere ancora più chiaro che un'espressione lambda è stata introdotta e dire qualcosa come "espressione 'arg' b 'arg' c 'funzione' " ;.

Capire come tradurre tutto questo in altre lingue è un esercizio per lo studente [; <).

Mi preoccupo ancora di " (b, c) = > espressione " e altre varianti che potrebbero nascere se non l'hanno già fatto. Forse " espressione 'args' b, c 'funzione' " ;.

Dopo tutto questo riflettere, noto che sto arrivando alla traduzione di " c = > e " come "funzione" lambda "c" e " e notando che la mappatura nella forma esatta deve essere compresa dal contesto: & # 955; c (e), c = > e, f dove f (c) = e, ecc.

Mi aspetto che il " vada a " la spiegazione prevarrà semplicemente perché è qui che la maggioranza dominante vedrà le espressioni lambda per la prima volta. È un peccato. Un buon compromesso potrebbe essere " c ' lambda-of ' e "

Se immagini un'espressione lambda come metodo anonimo, "vai a " ha abbastanza buon senso.

(n => n == String.Empty)

n " va in " l'espressione n == String.Empty.

Va ??al metodo anonimo, quindi non devi andare al metodo nel codice!

Mi dispiace per quello.

Onestamente, non mi piace usare " vai a " nella mia testa, ma ho visto altre persone dire che sembrava strano, e ho pensato di chiarirlo.

Oltre all'acquisizione dell'ambito precedente (tutte le variabili e le costanti che sono nell'ambito di una normale riga di codice nel punto in cui si verifica un'espressione lambda sono disponibili per il codice dell'espressione) un'espressione lambda è essenzialmente zucchero sintattico per un funzione in linea.

L'elenco di valori a sinistra dell'operatore di produzione (" = > ") contribuisce alla struttura e al contenuto del frame dello stack utilizzato per effettuare la chiamata a questa funzione. Si potrebbe dire che l'elenco dei valori contribuisce sia alle dichiarazioni dei parametri sia agli argomenti che vengono passati; nel codice più convenzionale determinano la struttura e il contenuto del frame dello stack utilizzato per effettuare la chiamata a una funzione.

Di conseguenza, i valori " vai a " il codice di espressione. Preferiresti dire che "definisce il frame dello stack per" oppure " vai a " ? :)

Nell'applicazione strettamente definita delle espressioni booleane utilizzate come condizioni di filtro (un uso dominante delle espressioni lambda ampiamente considerato da altre risposte a questa domanda) è molto ragionevole saltare il metodo a favore dell'intento del codice, e questo porta a " per cui " essere altrettanto concisi e dire di più sul significato del codice.

Tuttavia, le espressioni lambda non sono l'unica provincia di Linq e al di fuori di questo contesto la forma più generale "va a" dovrebbe essere usato.

Ma perché " vai a " ?

Perché " popola il frame dello stack del seguente codice " è troppo lungo per continuare a dirlo. Suppongo che potresti dire " è / sono passati a " ;.

Una differenza cruciale tra parametri passati esplicitamente e variabili acquisite (se ricordo bene, correggimi se sbaglio) è che i primi sono passati per riferimento e i secondi per valore.

Parte del problema è che puoi leggerlo ad alta voce in modo diverso a seconda di come è strutturato. È un peccato che non sia bello o integrato come quello di Ruby.

In Ruby, questo stesso sybmol è chiamato "hashrocket", " e ho sentito che anche i programmatori C # usano quel termine (anche se farlo è sbagliato).

I miei due centesimi:

s => s.Age > 12 && s.Age < 20

" Lambda Expression con parametro s è { return s.Age > 12 & amp; & amp; s.Age < 20; } "

Mi piace perché mi ricorda da dove viene l'espressione lamdba

delegate(Student s) { return s.Age > 12 && s.Age < 20; };

= > è solo una scorciatoia, quindi non è necessario utilizzare la parola chiave delegata e includere le informazioni sul tipo poiché possono essere dedotte dal compilatore.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow