为什么不使用.NET样式的委托而不是Java中的闭包？

Question

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

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

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

有两个非技术性的结论我很想进入:

1. Java社区应该保持自己的骄傲,代价是需要付出艰辛的努力,不要屈服于借用任何微软的概念或以其他方式证明微软的辉煌.
2. 代表是微软的专利技术.

好的,除了以上两种可能性,

Q1..NET风格的代理中是否存在三种(或更多种)封闭形式会解决的弱点或不足之处？

Q2.我在Java和C#之间转换时问这个问题,它让我感到兴奋的是C#代理完全符合我的需要.是否有可在C#代理中当前不可用的闭包中实现的功能？如果是这样,他们是什么因为我看不到我需要什么比C#代表给我足够的东西？

Q3.我知道在java中实现闭包/委托的一个问题是减少语言的正交性,其中不止一种方式暴露于执行特定任务.为了确保java保持其正交性水平,是否值得花费卷积和花费时间来避免代表？在关系设计中,我们知道通过经常充分满足第二范式而破坏正交性是可取的.为简单起见,为什么java不能减少正交性和OO-ness？

Q4.JVM的体系结构在技术上受限于实现.NET样式的委托.如果这个原因是:(虚拟语气强调祈)属实,那么为什么不能三个闭包方案是一个简单的委托关键字或注释背后隐藏的:如果我们不喜欢使用@Delegate,我们可以使用@method.我看不出委托语句格式如何比三个闭包提案更复杂.

Answer 1

你的问题具有讽刺意味.您想知道为什么Java社区正在努力解决添加闭包的三个不同提议,您建议的解决方案是添加第四个选项？

但要回答你的问题:

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

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

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

• C#有三种类型的委托表达式:旧的委托表达式使用委托关键字,语句lambdas使用=> {,表达式为lambdas.如果C#语言团队让它重新做,我们肯定没有这么多形式.Java为什么要采用C#的历史包袱？

• 因为C#泛型操作基元,所以Func <>和Action <>委托类型可以用作穷人的结构函数类型.但是在Java中,泛型被擦除,仅在引用类型上工作,并且类型不能通过它们的arity来区分.因此,Java必须拥有大量明显命名的"标准"函数类型才能获得相同的效果.那不太好看.

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

Answer 2

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

委托=函数指针。

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