他のプログラマーに会うことはめったにありません！
トークンを最初に見たときの私の考えは、それが数学的な証明のように読み取られるため、「それを意味する」でしたが、それは明らかにその意味ではありません。
では、「=>」の言い方や読み方は次のとおりです。
IEnumerable<Person> Adults = people.Where(p => p.Age > 16)
それとも、それを言う合意された方法さえありますか？
33918 次
16 に答える
150
その演算子を読むとき、私は通常「そのような」と言います。
あなたの例では、 p => p.Age > 16 は「p.Ageが16より大きいようなP」と読みます。
実際、公式の linq プレリリース フォーラムでまさにこの質問をしたところ、Anders Hejlsberg は次のように答えました。
私は通常 => 演算子を「becomes」または「for which」と読みます。たとえば、
Func f = x => x * 2;
Func test = c => c.City == "ロンドン";
「x が x * 2 になる」および「c.City が London に等しい c」と読みます。
「行く」限りでは、それは私には意味がありません。「p」はどこにも行きません。
たとえば、電話で誰かにコードを読む場合、彼らが C# プログラマーである限り、私は単に「ラムダ」という言葉を使用します。 16。"
コメントで、Steve Jessop は、変換の場合に「maps to」に言及しました。そのため、Anders の例を取り上げます。
x => x * 2;
読むだろう
x は x 倍の 2 にマップされます。
これは、この場合の「なる」というよりも、コードの実際の意図にはるかに近いようです。
于 2008-11-07T23:46:21.763 に答える
60
MSDNから:
すべてのラムダ式はラムダ演算子 => を使用します。これは「go to」と読みます。
于 2008-11-08T11:23:05.070 に答える
19
エリック・リッパート より:
私は個人的には c=>c+1 を「見るとプラス 1 を見る」と言うでしょう。私が聞いたいくつかのバリエーション：
プロジェクションの場合、 (Customer c)=>c.Name: "customer see takes see dot name"
述語の場合、 (Customer c)=>c.Age > 21: 「customer see such that see that see dot age is greater than 21」
于 2008-11-07T23:47:37.220 に答える
15
私はいつもそれを「王のオペレーター」と呼んでいます:-)
「pのpwang年齢が16より大きい」
于 2008-12-26T07:16:39.890 に答える
7
「矢印」と言う人を見たことがあります。
于 2008-11-07T23:47:46.457 に答える
7
LINQの本が私に言ったので、私は「goes to」を使用します:)
于 2008-11-07T23:48:30.060 に答える
5
「にマップ」はどうですか？それは簡潔であり、間違いなくより技術的に正確です (つまり、「goes to」または「becomes」のように状態変化を示唆するものではなく、「so that that」または「for which」のようにセットとその特徴的な機能を混同することはありません)。他の選択肢。ただし、MSDN ページが暗示しているように見える標準が既に存在する場合は、それを使用する必要があります (少なくとも C# コードの場合)。
于 2010-01-24T21:14:17.107 に答える
3
「Maps to」は私の好みの発音です。数学的に言えば、関数はその引数をその戻り値に「マッピング」します (関数を「マッピング」と呼ぶことさえあります)。そのため、この用語をプログラミングで、特に関数型プログラミング (特にラムダ計算) として使用することは理にかなっています。数学にとても近いです。また、コンテキストフリーが述べたように、状態の変化を示唆していないため、「なる」、「行く」などよりも中立的です。
于 2010-01-24T21:27:39.460 に答える
2
ラムダ式が匿名メソッドであると想像すると、「go to」は十分に理にかなっています。
(n => n == String.Empty)
n は、式 n == String.Empty に「移動」します。
匿名メソッドに行くので、コード内のメソッドに行く必要はありません!
そのために残念。
正直なところ、頭の中で「goes to」を使うのは好きではありませんが、他の人が変だと言っているのを見て、それを片付けようと思いました。
于 2013-04-29T03:45:19.160 に答える
2
前述のスコープ (ラムダ式が発生した時点で通常のコード行のスコープ内にあるすべての変数と定数を式のコードで使用できる) を取得することは別として、ラムダ式は本質的にインライン関数のシンタックス シュガーです。
生成演算子 ("=>") の左側にある値のリストは、この関数の呼び出しに使用されるスタック フレームの構造と内容に寄与します。値のリストは、渡されるパラメーター宣言と引数の両方に貢献していると言えます。より一般的なコードでは、これらは関数の呼び出しに使用されるスタック フレームの構造と内容を決定します。
その結果、値は式コードに「移動」します。「のスタックフレームを定義する」または「に行く」と言いますか？:)
フィルター条件として使用されるブール式の狭義に定義されたアプリケーション (この質問に対する他の回答で広く検討されているラムダ式の支配的な使用) では、コードの意図を優先してメソッドをスキップすることは非常に合理的であり、これは "そのため」と同じくらい簡潔で、コードの意味について詳しく述べています。
ただし、ラムダ式は Linq の唯一の領域ではなく、このコンテキストの外では、より一般的な形式 "gos to" を使用する必要があります。
しかし、なぜ「に行く」のですか？
「次のコードのスタック フレームにデータを入力する」というのは長すぎて、言い続けることができないからです。「is/are passed to」と言えると思います。
明示的に渡されたパラメーターとキャプチャーされた変数 (私の記憶が正しければ - 間違っている場合は訂正してください) の決定的な違いは、前者は参照によって渡され、後者は値によって渡されることです。
于 2008-11-08T01:15:57.357 に答える
2
あまり考えたことがありませんが、簡潔に「to」とだけ言っておきます。これは短く簡潔で、変数が式に渡されることを意味します。数字の2（「ツー」）と混同される可能性があると思いますが、話すときは「と」の方が「た」のように発音する傾向があります。誰も（少なくともラムダを知っている）あいまいだと思ったことはありません...
// "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"
于 2008-11-08T02:28:45.400 に答える
2
私の短い答え：「c 'lambda-of' e」。私は「'lambda' c 'function' e」にしがみついていますが、lambda-of はエキュメニカルな妥協点だと思います。分析は次のとおりです。
奇妙な答えのためだけなら、これは素晴らしい質問です。ほとんどの翻訳は、ラムダ式以外の意味を持ち、風変わりな解釈につながります。昔からのラムダ式ハッカーとして、.NET 表記を無視して頭の中でラムダ式に書き直しましたが、このために他のほとんどのことをしてくれたらよかったのにと思います。
電話でコードをナレーションする場合、誰かがコードを順番に書き留められるようにする必要があります。もちろん、それは問題ですが、ラムダ矢印または何かがおそらく取得できる最高のものであるか、ラムダインである可能性がありますが、ラムダオブが最も正確です。
問題は、中置詞の使い方と全体の名前の付け方と、中置詞の場所で話されたときに機能するもので、左右の部分の役割です。
これは、制約が過剰な問題である可能性があります。
「そのような」は使用しません。これは、右側が左側が満たすべき述語であることを意味するためです。これは、関数パラメーターとして左辺が抽象化された右辺について話すこととは大きく異なります。(「すべてのラムダ式」に関する MSDN の声明は、単に攻撃的であり、不正確です。)
私たちが得ることができる限り近いかもしれませんが、何かが「行く」ことについて不平を言います。「に行く」は変換を意味しますが、c の式に行く変数 c は正確にはありません。関数への抽象化は少しわかりにくいです。これに慣れることはできますが、変数の抽象化を強調するものに憧れています。
これまでに使用された場合、左辺は常に単純な識別子であるため [ただし、後でこれを混乱させる可能性のある拡張機能を待ちます]、「c => 式」の場合は「c 'lambda-function' 式」と読むと思います"' または "c 'arg' 'function' 式". 最後のケースでは、「b 'arg' c 'arg' 'function' expression」のようなことを言うことができます。
ラムダ式が導入されていることをさらに明確にして、「'arg' b 'arg' c 'function' expression」のように言った方がよいかもしれません。
これらすべてを他の言語に翻訳する方法を理解することは、学生の課題です [;<)。
私はまだ「(b, c) => 式」やその他のバリアントがまだ存在しない場合に発生する可能性があることを心配しています。おそらく「'args' b, c 'function' 式」です。
このすべての熟考の後、私は "c => e" を "'lambda' c 'function' e" に翻訳しようとしていることに気づき、正確な形式へのマッピングはコンテキストによって理解されることに気付きました: λc(e )、c => e、fここでf(c) = e など。
私は、圧倒的多数がラムダ式を初めて目にする場所であるという理由だけで、「行き先」の説明が優勢になると予想しています。それは残念だ。良い妥協点は "c ' lambda-of ' e"かもしれません
于 2008-11-08T19:43:49.037 に答える
1
Ruby では、この同じ記号を「ハッシュロケット」と呼びます。C# プログラマーもこの用語を使用していると聞きました (使用するのは間違っていますが)。
于 2013-09-30T20:41:07.130 に答える
1
問題の一部は、それがどのように構成されているかに応じて、声に出して読むことができるということです. Ruby の | ほどきれいでもなく、統合されていないのは残念です。
于 2008-11-07T23:49:19.947 に答える
0
私の2セント：
s => s.Age > 12 && s.Age < 20
「パラメータ s を持つラムダ式は { return s.Age > 12 && s.Age < 20;} です」
ラムバ式がどこから来たのかを思い出させるので、私はこれが好きです
delegate(Student s) { return s.Age > 12 && s.Age < 20; };
=> は単なるショートカットであるため、デリゲート キーワードを使用して型情報を含める必要はありません。これは、コンパイラによって推論できるためです。
于 2015-06-08T16:57:48.277 に答える