为什么不呢。在Java中,NET风格的委托而不是闭包?
好吧,这将是我第三次击败一匹垂死的马。
但是,这个问题与我之前关于闭包/委托的两个问题不同,后者询问了委托的计划以及闭包的预计规范和实现。
这个问题是关于 - 为什么Java社区正在努力定义3种不同类型的闭包,而我们可以简单地从我们心爱和友好的邻居 - 微软窃取代表锁,股票和桶的整个概念。
有两个非技术性的结论,我非常想跳进去:
- Java社区应该保持自豪感,代价是需要付出复杂的努力,不屈服于借用任何微软概念或以其他方式证明微软的辉煌。
- Delegates是微软的一项专利技术。
好吧,除了上述两种可能性,
问题 1.中是否有任何弱点或不足三种(或更多)形式的闭包将解决的 NET 样式委托?
问题 2.我在Java和C#之间转换时问这个问题,这让我很感兴趣,C#委托完全符合我的需求。是否有将在 C# 委托中当前不可用的闭包中实现的功能?如果是这样,它们是什么,因为我看不到我需要什么,而不是C#委托为我提供足够的东西?
问题 3.我知道在java中实现闭包/委托的一个问题是减少语言的正交性,其中有多种方式被公开来执行特定的任务。是否值得使用级别卷积和时间来避免委托,以确保java保持其正交性级别?在关系设计中,我们知道通过经常仅充分满足第二范式来打破正交性是可取的。为什么Java不能为了简单而减少正交性和OO-ness?
问题 4.JVM 的体系结构在技术上受到限制,无法实现 。网络样式的委托。如果这个原因是正确的(为了强调不太可能,那么为什么三个闭包提案不能隐藏在一个简单的委托关键字或注释后面:如果我们不喜欢使用@delegate,我们可以使用@method。我看不出代表声明格式比三个关闭提案更复杂。