Pergunta

I muito raramente se encontram quaisquer outros programadores!

Meu pensei quando vi pela primeira vez o token foi "implica que" uma vez que é o que iria lê-lo como em uma prova matemática, mas que claramente não é o seu sentido.

Então, como eu digo ou ler "=>" como em: -

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

Ou há mesmo uma forma acordada de dizê-lo?

Foi útil?

Solução

Eu costumo dizer 'tal que' ao ler esse operador.

No seu exemplo, p => p.Age> 16 lê como "P, de tal forma que p.Age é maior do que 16".

Na verdade, eu fiz esta mesma pergunta no fórum oficial linq de pré-lançamento, e Anders Hejlsberg respondeu dizendo

Eu costumo ler o operador => como "torna-se" ou "para que". Por exemplo,
Func f = x => x * 2;
teste Func = c => c.City == "London";
lê como "x torna-se x * 2" e "c para a qual c.City igual London"

No que diz respeito 'vai para' - que nunca fez sentido para mim. 'P' não vai a lugar nenhum.

No caso de leitura de código para alguém, digamos, por telefone, então, enquanto eles são um companheiro programador C #, eu tinha acabado de usar a palavra 'lambda' - isto é, "p idade lambda p dot maior que dezesseis ".

Em comentários Steve Jessop mencionados 'mapas para' no caso das transformações - assim que tomar exemplo Anders':

x => x * 2;

leria

x mapeia para x vezes 2.

Isso faz parecer muito mais próxima da intenção real do código do que 'se torna' para este caso.

Outras dicas

A partir MSDN :

Todas as expressões lambda usar o lambda operador =>, que é lido como "vai com".

leitura de código Durante o telefone

De Eric Lippert:

Eu, pessoalmente, diria c => c + 1 como "see vai ver mais um". Algumas variações que ouvi:

Para uma projeção, (Customer c) => c.Name: "cliente ver torna-se ver o nome dot"

Para um predicado, (Customer c) => c.Age> 21: "cliente ver tal que ver idade dot é maior do que vinte e um"

Eu sempre chamou de "operador wang": -)

"idade p wang de p superior a 16"

Eu vi as pessoas dizem, "Arrow".

Eu uso "vai para", porque um livro LINQ me disse para:)

Como sobre "mapeia para"? É tanto sucinta e sem dúvida mais tecnicamente precisa (ou seja, nenhuma sugestão de uma mudança de estado como com "vai" ou "torna-se", sem fusão de um conjunto com a sua função característica como com "tal que" ou "para que") do que o outras alternativas. Embora se já existe um padrão como a página aparece MSDN implicar, talvez você deve apenas ir com que (pelo menos para código C #).

"Maps para" é a minha pronúncia preferido. Matematicamente falando, uma função "mapeia" os seus argumentos ao seu valor de retorno (uma pode até chamar a função de um "mapeamento"), por isso faz sentido para mim usar essa terminologia na programação, nomeadamente em programação funcional (especialmente o cálculo lambda) está muito perto de matemática. Também é mais neutro do que "torna-se", "vai para", etc., uma vez que não sugere mudança de estado, como contextfree mencionado.

Eu não pensei que sobre muito, mas eu só sucintamente dizer "para". É curto e conciso, e implica que a variável é passada para a expressão. Suponho que poderia ser confundido com o numeral 2 ( "dois"), mas eu tendem a pronunciar "para" mais como "ta" quando se fala. Ninguém (quem sabe lambdas, pelo menos) já me disseram que ele ambígua ...

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

A minha resposta curta: "c 'lambda-de' e". Embora eu estou agarrando-se a " 'lambda' c 'função' e", eu acho que lambda-of é o compromisso ecumênico. Análise segue.

Esta é uma grande questão se apenas para as respostas bizarras. A maioria das traduções têm outros significados do que para as expressões lambda, levando a interpretações exóticas. Como um hacker de lambda-expressão de idade, eu simplesmente ignorar a notação .NET e reescrevê-lo como lambda na minha cabeça enquanto desejando que eles tinham feito quase qualquer outra coisa para isso.


Para narrar código por telefone, você quer alguém para ser capaz de escrever o baixo código em seqüência. Isso é um problema, é claro, mas lambda-flecha ou algo é provavelmente o melhor que você pode obter, ou talvez lambda-in, mas lambda-of é o mais preciso.

O problema é o uso infix e como nomear a coisa toda e o papel das partes esquerda e direita com algo que funciona quando se fala no lugar infix.

Isso pode ser um problema de sobre-constrangido!


Eu não usaria "tal que" porque isso implica que o lado direito é um predicado que o lado esquerdo deve satisfazer. Isso é muito diferente de falar sobre um lado direito a partir do qual o lado esquerdo foi captada como um parâmetro funcional. (A declaração MSDN sobre "Todas as expressões lambda" é simplesmente ofensiva, bem como impreciso.)

rankles algo sobre "vai para" embora possa ser o mais próximo que podemos chegar. "Vai para" implica uma transformação, mas não é exatamente alguma c variável que vai para uma expressão em c. A abstração para uma função é um pouco evasivo. Eu poderia se acostumar com isso, mas eu ainda anseiam por algo que enfatiza a abstração da variável.

Uma vez que o lado esquerdo é sempre um identificador simples nos casos utilizado até agora [mas espera para extensões que podem confundir isso mais tarde], acho que para "c => expressão" Eu lia "c 'lambda ' expressão da função "' ou mesmo 'expressão c 'arg' 'função''. No último caso, eu poderia então dizer coisas como "b 'arg' c 'arg' '' expressão de função".

Pode ser melhor para torná-lo ainda mais claro que a lambda-expressão está sendo introduzido e dizer algo como " 'arg' b 'arg' c 'função' expressão".

Descobrir como traduzir tudo isso para outras línguas é um exercício para o aluno [;. <)

Eu ainda se preocupar com "(b, c) => expressão" e outras variantes que podem vir a existir se não tiver já. Talvez " 'args' b 'função' c expressão".


Depois de tudo isto devaneio, noto que estou vindo para traduzindo "c => e" como " 'lambda' c 'função' e" e notando que o mapeamento de forma exata deve ser entendida pelo contexto: ?c (e), C => e, f onde F (C) = e, etc.

Eu espero que o "vai-a" explicação vai prevalecer simplesmente porque este é o lugar onde a maioria dominante vai ver as expressões lambda, pela primeira vez. É uma pena. Um bom compromisso pode ser "c ' lambda-de ' e"

Se você imaginar uma expressão lambda como o método anônimo que é, "vai para" faz o suficiente sentido decente.

(n => n == String.Empty)

n "vai para" a expressão n == String.Empty.

Ele vai para o método anônimo, para que você não tem que ir para o método no código!

Desculpe por isso.

Honestamente, eu não gosto de usar "vai para" em minha cabeça, mas eu vi outras pessoas dizendo que parecia estranho, e eu pensei que eu ia deixar isso claro.

Para além da aquisição do âmbito anterior (todas as variáveis ??e constantes que estão no âmbito de uma linha normal de código no ponto onde uma expressão lambda ocorre estão disponíveis para o código da expressão) uma expressão lambda é açúcar essencialmente sintático para uma função inline.

A lista de valores à esquerda do operador de produção ( "=>") contribui a estrutura eo conteúdo do quadro de pilha usado para fazer a chamada para esta função. Pode-se dizer que a lista de valores contribui tanto as declarações de parâmetros e os argumentos que são passados; em código mais convencional estes determinam a estrutura eo conteúdo do quadro de pilha usado para fazer a chamada para uma função.

Como resultado, os valores "ir para" o código de expressão. Você prefere dizer "define o quadro de pilha para" ou "vai para"? :)

Na aplicação estritamente definido de expressões booleanas utilizadas como condições de filtro (um uso dominante de expressões lambda amplamente considerados por outras respostas a esta pergunta) é muito razoável para ignorar o método a favor da intenção do código, e este leva a "para o qual" ser tão sucinto e dizer mais sobre o significado do código.

No entanto, as expressões lambda não são a única província de Linq e fora deste contexto a forma mais geral "vai para" deve ser usado.


Mas por "vai para"?

Porque "preenche o quadro de pilha do código a seguir" é muito tempo para manter dizendo isso. Eu suponho que você poderia dizer "é / são passados ??para".

A diferença crucial entre os parâmetros passados ??explicitamente e variáveis ??capturados (se bem me lembro - me corrija se eu estiver errado) é que os primeiros são passados ??por referência e esta última por valor

.

Parte do problema é que você pode ler em voz alta de forma diferente dependendo de como ele está estruturado. É uma pena que não é tão bonita ou tão integrado quanto do rubi |. 'S

Em Ruby, este mesmo sybmol é chamado de "Hashrocket," e eu ouvi programadores C # usar esse termo também (mesmo que isso é errado).

Os meus dois centavos:

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

"Lambda Expression com o parâmetro s é {return s.Age > 12 && s.Age < 20;}"

Eu gosto deste porque me lembra de onde a expressão lamdba vem

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

=> é apenas um atalho para que você não tem que usar a palavra-chave delegado e incluem a informação tipo, uma vez que pode ser inferido pelo compilador.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top