为什么不是 .NET 风格的委托而不是 Java 中的闭包？

Question

好吧，这将是我第三次打死马了。

但是，这个问题与我之前关于闭包/代表的两个问题不同，后者询问代表的计划以及闭包的预计规范和实施。

这个问题是关于 - 为什么 Java 社区在努力定义 3 种不同类型的闭包时，我们可以简单地从我们心爱的友好邻居微软那里窃取委托锁、股票和桶的整个概念。

有两个非技术性的结论我很想跳入：

1. Java 社区应该保持其自豪感，但需要付出复杂的努力，不要屈服于借用任何 Microsoft 概念或以其他方式证明 Microsoft 的才华。
2. Delegates 是 Microsoft 的专利技术。

好吧，除了以上两种可能，

第一季度。三种（或更多）形式的闭包要解决的 .NET 风格的委托是否存在任何弱点或不足之处？

第二季度。我在 Java 和 C# 之间切换时问这个问题，这让我很感兴趣，C# 委托完全符合我的需要。是否有将在 C# 委托中当前不可用的闭包中实现的功能？如果是这样，它们是什么，因为我看不到我需要的东西比 C# 代表充分提供给我的东西更多？

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

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

Answer 1

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

但要回答你的问题：

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

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

• Java 的发展必须保持向后兼容，但添加委托关键字将是一项重大更改。

• C# 具有三种类型的委托表达式：带有委托关键字的旧的一种、带有 =>{ 的语句 lambda 和表达式 lambda。如果 C# 语言团队要重新做一遍，我们肯定不会有这么多形式。 Java 为什么要背负 C# 的历史包袱？

• 因为 C# 泛型对原语进行操作，所以 Func 和 Action 委托类型可以用作穷人的结构函数类型。但是在 Java 中，泛型被删除了，只对引用类型起作用，并且类型不能通过它们的数量来区分。因此，Java 必须拥有大量明确命名的“标准”函数类型才能获得相同的效果。那可不好看。

总体而言，C# 解决方案不适应 Java 中非常自然的解决方案。

Answer 2

C# 除了委托之外还有闭包。在我看来，它们并不相同。

委托 = 函数指针。

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