如何在.Net中使用lambdaexpression式中的“=>”

我很less遇到其他程序员!

当我第一次看到这个标记的时候,我的想法是“暗示着”,因为这就是它在math上certificate的那样,但这显然不是它的意义。

那么我怎么说或读“=>”如下:

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

还是甚至有一种同意的说法呢?

在阅读该操作员时,我通常会这样说。

在你的例子中,p => p.Age> 16读作“P,这样p.Age大于16”。

事实上,我在官方的linq预发布论坛上问了这个问题,Anders Hejlsberg回答说

我通常将=>运算符读作“变成”或“为此”。 例如,
Func f = x => x * 2;
Func test = c => c.City ==“London”;
读作“x变为x * 2”和“c为c.City等于伦敦”

就“去”而言 – 这对我来说是没有意义的。 “p”不会去任何地方。

在通过电话阅读代码的情况下,只要他们是C#程序员,我就用“lambda”这个词 – 也就是“p lambda p dot age more than than十六。”

在评论中,Steve Jessop在转换的情况下提到了“地图” – 所以以安德斯为例:

 x => x * 2; 

会读

x映射到x次2。

对于这种情况,这看起来似乎更接近代码的实际意图。

来自MSDN :

所有的lambdaexpression式都使用lambda运算符=>,读作“去”。

通过电话阅读代码

来自Eric Lippert:

我个人会说c => c + 1为“看去看看再加上一个”。 我听说过的一些变化:

对于一个投影,(客户c)=> c.Name:“客户看到变成见点名”

对于一个谓词,(客户c)=> c.Age> 21:“客户看到这样的看点时间大于二十一”

我一直把它叫做“旺运营商”:-)

“p大于16岁”

我使用“去”,因为LINQ书告诉我:)

我见过有人说“箭”。

如何“映射到”? 它既简洁又可以说在技术上更为精确(即,没有像“去”或“成为”那样的状态变化的提示,也没有与具有其“特征”function的集合的集合,比如“这样”或“为什么”)其他select。 虽然如果已经有一个标准的MSDN页面似乎暗示,也许你应该去(至less对于C#代码)。

“地图到”是我的首选发音。 在math上,一个函数将它的参数“映射”到它的返回值(甚至可能把函数称为“映射”),所以在编程中使用这个术语是有意义的,特别是函数式编程(特别是lambda演算)非常接近math。 它也比“变”,“去”等更为中性,因为它没有提到状态的改变,就像上文提到的那样。

我没有想太多,但我只是谦恭地说“要”。 它简洁明了,意味着variables被传递expression式。 我认为它可能与数字2(“2”)混淆,但我倾向于在发音时更像“ta”。 没有人(谁知道lambda,至less)曾告诉我,他们认为这是模糊的…

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

我简短的回答:“c”lambda – “e”。 尽pipe我坚持“lambda”“c”函数“e”,但我认为lambda是普遍的妥协。 分析如下。

如果只是为了奇怪的答案,这是一个很好的问题。 大多数翻译与lambdaexpression有其他的含义,导致异国情调的解释。 作为一个老式的lambdaexpression式黑客,我只是忽略了.NET符号,并且把它重写为lambda,同时希望他们已经为此做了其他任何事情。


为了通过电话叙述代码,你希望有人能够按顺序写下代码。 这当然是一个问题,但是lambda-arrow或者其他东西可能是最好的,或者lambda-in,但是lambda-of是最准确的。

问题在于中缀的使用方法,以及如何在中缀的地方说出所有东西和左右部分的作用,以及一些有用的东西。

这可能是一个过度约束的问题!


我不会使用“这样的”,因为这意味着右侧是左侧应该满足的谓词。 这与将左手边抽象为function性参数的右手边截然不同。 (有关“所有lambdaexpression式”的MSDN声明仅仅是令人反感和不准确的。)

尽pipe可能会尽可能地接近我们所能得到的东西, “go to”意味着一个转换,但是在c中没有一个variablesc。 对函数的抽象是有点难以捉摸的。 我可以习惯这个,但我仍然渴望某些强调抽象variables的东西。

由于左侧在目前使用的情况下总是一个简单的标识符(但是等待后面可能会混淆的扩展名),我认为对于“c =>expression式”,我会读取“c'lambda-function”expression式“”甚至“c”arg“”函数“expression式”。 在最后一个例子中,我可以这样说:“b”arg“c”arg“”函数“expression式”。

这可能会更好地使一个lambdaexpression式被引入,并且像“'arg'b'arg'c''函数'expression式'那样。

搞清楚如何将所有这些翻译成其他语言是对学生[; <)的练习。

我仍然担心“(b,c)=>expression”和其他可能会产生的变种,如果他们还没有。 也许“'args'b,c'function”expression“。


在所有这些思考之后,我注意到我正在将“c => e”翻译为“'lambda'c'函数'e”,并且注意到通过上下文来理解映射到确切forms:λc(e ),c => e,f 其中 f(c)= e等

我预计“前往”的解释将占上风,因为这是绝大多数人首次会看到拉姆达expression式的地方。 太可惜了。 一个很好的妥协可能是“c” lambda – “e”

如果你想象一个lambdaexpression式作为匿名方法,那么“去”就足够了。

 (n => n == String.Empty) 

n“转到”expression式n == String.Empty。

它转到匿名方法,所以你不必去代码中的方法!

对不起。

老实说,我不喜欢用头脑中的“去”,但我看到其他人说这看起来很奇怪,我想我会清楚的。

除了获得前面的范围(在expression式的代码中可以使用lambdaexpression式所在位置的所有正常代码行的variables和常量),lambdaexpression式本质上是内联函数的语法糖。

生产操作符左边的值列表(“=>”)贡献了用于调用此函数的堆栈框架的结构和内容。 你可以说,值的列表有助于参数声明和传递的参数。 在更传统的代码中,这些决定了用于调用函数的堆栈帧的结构和内容。

结果,值“转到”expression式代码。 你想说“定义栈帧”还是“去”? 🙂

在用作过滤条件的布尔expression式的狭义定义的应用中(对这个问题的其他答案广泛地考虑了lambdaexpression式的主要用途),跳过该方法以支持代码的意图是非常合理的,并且这导致“为此,“就像简洁的一样,更多地谈论代码的含义。

但是,lambdaexpression式并不是Linq的唯一省份,除此之外,应该使用更一般的forms“去”。


但为什么“去”呢?

因为“填充以下代码的堆栈框架”太长了,不能一直说下去。 我想你可以说“被传递给”。

显式传递的参数和捕获的variables之间的关键区别(如果我没有记错的话 – 纠正我,如果我错了)是前者通过引用传递,后者通过值。

问题的一部分是,根据结构的不同,你可以大声朗读。 这是一个耻辱,它不像ruby一样漂亮或整合。

在Ruby中,这个sybmol被称为“hashrocket”,我也听说C#程序员也使用这个术语(即使这样做是错误的)。

我的两分钱:

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

“参数s的Lambdaexpression式是{ return s.Age > 12 && s.Age < 20; }”

我喜欢这个,因为它让我想起lamdbaexpression来自哪里

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

=>只是一个快捷方式,所以你不必使用委托关键字,并包含types信息,因为它可以被编译器推断出来。