为什么不呢。在Java中,NET风格的委托而不是闭包?

2022-09-02 20:11:14

好吧,这将是我第三次击败一匹垂死的马。

但是,这个问题与我之前关于闭包/委托的两个问题不同,后者询问了委托的计划以及闭包的预计规范和实现。

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

有两个非技术性的结论,我非常想跳进去:

  1. Java社区应该保持自豪感,代价是需要付出复杂的努力,不屈服于借用任何微软概念或以其他方式证明微软的辉煌。
  2. Delegates是微软的一项专利技术。

好吧,除了上述两种可能性,

问题 1.中是否有任何弱点或不足三种(或更多)形式的闭包将解决的 NET 样式委托?

问题 2.我在Java和C#之间转换时问这个问题,这让我很感兴趣,C#委托完全符合我的需求。是否有将在 C# 委托中当前不可用的闭包中实现的功能?如果是这样,它们是什么,因为我看不到我需要什么,而不是C#委托为我提供足够的东西?

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

问题 4.JVM 的体系结构在技术上受到限制,无法实现 。网络样式的委托。如果这个原因是正确的(为了强调不太可能,那么为什么三个闭包提案不能隐藏在一个简单的委托关键字或注释后面:如果我们不喜欢使用@delegate,我们可以使用@method。我看不出代表声明格式比三个关闭提案更复杂。


答案 1

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

但要回答你的问题:

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

  • C# 和 Java 的类型系统有很大不同,因此 C# 解决方案不会直接应用。例如,C# 具有声明站点方差(in/out),而 java 具有 use-site 方差(通配符)。在 C# 中指定的 lambda 参数类型的推理不适用于 Java。

  • Java的发展必须保持向后兼容,但添加委托关键字将是一个重大的变化。

  • C# 有三种类型的委托表达式:带有 delegate 关键字的旧表达式、带有 =>{ 的语句 lambda 和表达式 lambda。如果 C# 语言团队需要重新做一遍,我们肯定不会有这么多的形式。为什么Java应该采用C#的历史包袱?

  • 由于 C# 泛型对基元进行操作,因此 Func<>和 Action<> 委托类型可用作穷人的结构函数类型。但是在Java中,泛型被擦除,只在引用类型上工作,并且类型不能通过其arity来区分。因此,Java必须具有大量名称明确的“标准”函数类型才能获得相同的效果。那可不漂亮。

总的来说,C#解决方案不能适应Java中非常自然的解决方案。


答案 2

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

委托 = 函数指针。

闭包 = {函数,环境}。定义 [匿名] 函数并将其与其环境打包在一起的方式。严格来说,后者应该只被称为闭包,前者是“lambda表达式”。