为什么不呢。Java中的NETstyle委托而不是闭包？

Question

好吧，这将是我第三次打败一匹奄奄一息的马

但是，这个问题不同于我前面两个关于闭包/委托的问题，后者询问委托的计划以及闭包的预计规格和实现

这个问题是关于-为什么Java社区在定义3种不同类型的闭包时会举步维艰，而我们可以从我们亲爱的友好邻居微软那里简单地窃取代理锁、股票和桶的整个概念

我很想得出两个非技术性的结论：

1. Java社区应该保持它的自豪感，而不是屈从于借用任何微软的概念或以其他方式为微软的辉煌辩护，这是以需要付出错综复杂的努力为代价的
2. 代理是微软的专利技术

好,除了上述两种可能之外,

问题1。是否有任何弱点或不足之处。NET风格的委托，三种（或更多）形式的闭包将要处理哪些委托

问题2。我在Java和C之间转换时问了这个问题，C#委托正是我所需要的。是否有将在闭包中实现的功能，而这些功能目前在C#delegate中不可用？如果是这样的话，那是因为我看不到我需要的东西比C#delegations充分提供给我的东西更多

第三季度。我知道，在java中实现闭包/委托的一个问题是减少语言的正交性，在这种情况下，可以使用多种方法来执行特定任务。为了确保java保持其正交性水平而避免委托所花费的时间和水平卷积值得吗？在关系设计中，我们知道通过经常充分满足第二范式来打破正交性是可取的。为什么java不能为了简单而减少正交性和OO性

第四季度。JVM的体系结构在技术上受到限制，无法实现。网络风格的代表。如果这个原因是真的（虚拟的，强调不太可能），那么为什么三个闭包方案不能隐藏在一个简单的委托关键字或注释后面：如果我们不喜欢使用@delegate，我们可以使用@method。我看不出委托语句格式比三个结束建议更复杂

Answer 1

你的问题很讽刺。您想知道为什么Java社区正在为添加闭包的三种不同方案而苦苦挣扎，而您建议的解决方案是在组合中添加第四种方案

但要回答你的问题：

• 讨论的正确论坛是openjdk项目lambda的邮件列表。这不是一个建议可能会影响这一努力的地方

• C#和Java的类型系统明显不同，因此C#解决方案不会直接应用。例如，C#具有声明站点差异（in/out），而java具有使用站点差异（通配符）。C#中指定的lambda参数类型的推断在Java中不适用

• Java的发展必须保持向后兼容，但添加delegate关键字将是一个突破性的变化

• C#有三种类型的委托表达式：带有delegate关键字的旧表达式，语句lambdas with=>；{，还有表达式lambdas。如果C语言团队要重新做，我们肯定不会有这么多形式。为什么Java要采用C语言的历史包袱？

• 由于C#泛型在原语上操作，因此Func<&燃气轮机；和行动<&燃气轮机；委托类型可以用作穷人的结构函数类型。但在Java中，泛型被删除，只对引用类型起作用，并且类型不能通过它们的算术来区分。因此，Java必须有大量名称明确的“标准”函数类型才能获得相同的效果。那可不太好

总的来说，C#解决方案不适合Java中非常自然的解决方案

Answer 2

C#除了委托之外还有闭包。在我看来，它们是不一样的

委托=函数指针

闭包={function，environment}。 定义[匿名]函数并将其与其环境打包的方法。严格来说，后者只能称为闭包，前者是“lambda表达式”