为什么不在 Java 中使用 .NET 风格的委托而不是闭包？
好吧，这将是我第三次打败一匹垂死的马。
然而，这个问题与我之前关于闭包/代表的两个问题不同，后者询问代表的计划以及闭包的预计规格和实现是什么。
这个问题是关于——为什么 Java 社区正在努力定义 3 种不同类型的闭包，而我们可以简单地从我们亲爱的友好邻居 Microsoft 那里窃取委托锁、库存和桶的整个概念。
我很想跳出两个非技术性的结论：
- Java 社区应该保持其自豪感，但代价是需要付出复杂的努力，不要屈服于借用任何 Microsoft 概念或以其他方式证明 Microsoft 的辉煌。
- Delegates 是一项 Microsoft 专利技术。
好吧，除了上面两种可能之外，
Q1。三种（或更多）形式的闭包要解决的 .NET 风格委托中是否存在任何弱点或不足？
Q2。我在 Java 和 C# 之间切换时问了这个问题，这让我很感兴趣，C# 委托正是我所需要的。是否有一些可以在闭包中实现但目前在 C# 委托中不可用的功能？如果是的话，它们是什么，因为我看不到除了 C# 委托充分提供给我的东西之外我还需要什么？
Q3。我知道在 java 中实现闭包/委托的担忧之一是减少语言的正交性，其中公开了不止一种方法来执行特定任务。为了确保 java 保持其正交性级别而花费级别卷积和避免委托是否值得？在关系设计中，我们知道最好通过经常充分满足第二范式来打破正交性。为什么java不能为了简单起见减少正交性和面向对象性？
Q4。 JVM 的体系结构在技术上受到实现 .NET 风格的委托的限制。如果这个原因是真的（强调不可能的虚拟语气），那么为什么不能将三个闭包提案隐藏在简单的委托关键字或注释后面：如果我们不喜欢使用@delegate，我们可以使用@method。我看不出委托语句格式比三个关闭提案更复杂。
OK, this is going to be my beating a dying horse for the 3rd time.
However, this question is different from my earlier two about closures/delegates, which asks about plans for delegates and what are the projected specs and implementation for closures.
This question is about - why is the Java community struggling to define 3 different types of closures when we could simply steal the whole concept of delegates lock, stock and barrel from our beloved and friendly neighbour - Microsoft.
There are two non-technical conclusions I would be very tempted to jump into:
- The Java community should hold up its pride, at the cost of needing to go thro convoluted efforts, by not succumbing to borrowing any Microsoft concepts or otherwise vindicate Microsoft's brilliance.
- Delegates is a Microsoft patented technology.
Alright, besides the above two possibilities,
Q1. Is there any weakness or inadequacy in .NET-style delegates that the three (or more) forms of closures would be addressing?
Q2. I am asking this while shifting between Java and C# and it intrigues me that C# delegates does exactly what I needed. Are there features that would be implemented in closures that are not currently available in C# delegates? If so what are they because I cannot see what I need more than what C# delegates has adequately provided me?
Q3. I know that one of the concerns about implementing closures/delegates in java is the reduction of orthogonality of the language, where more than one way is exposed to perform a particular task. Is it worth the level convolution and time spent to avoid delegates just to ensure java retains its level of orthogonality? In relational design, we know that it is advisable to break orthogonality by frequently adequately satisfying only the 2nd normal form. Why can't java be subjected to reduction of orthogonality and OO-ness for the sake of simplicity?
Q4. The architecture of JVM is technically constrained from implementing .NET-styled delegates. If this reason WERE (subjunctive to emphasize unlikelihood) true, then why can't the three closures proposals be hidden behind a simple delegate keyword or annotation: if we don't like to use @delegate, we could use @method. I cannot see how delegate statement format is more complex than the three closure proposals.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
你的问题很讽刺。您想知道为什么 Java 社区正在努力解决添加闭包的三种不同建议，而您建议的解决方案是添加第四个选项？
但要回答你的问题：
讨论的正确论坛是 openjdk 项目 lambda 的邮件列表。这里的建议不会影响这项工作。
C# 和 Java 的类型系统有很大不同，因此 C# 解决方案不能直接应用。例如，C# 具有声明位置差异（输入/输出），而 Java 具有使用位置差异（通配符）。 C# 中指定的 lambda 参数类型推断不适用于 Java。
Java 的发展必须保持向后兼容，但添加 delegate 关键字将是一个重大更改。
Java 的发展必须保持向后兼容
C# 具有三种类型的委托表达式：带有 delegate 关键字的旧委托表达式、带有 =>{ 的语句 lambda 表达式以及表达式 lambda 表达式。如果C#语言团队重来一次，我们肯定不会有这么多的形式。为什么 Java 要采用 C# 的历史包袱？
因为 C# 泛型对原语进行操作，所以 Func<>和动作>>委托类型可以用作穷人的结构函数类型。但在 Java 中，泛型被删除，仅对引用类型起作用，并且类型不能通过其数量来区分。因此，Java 必须拥有大量名称明确的“标准”函数类型才能获得相同的效果。这不太好。
总的来说，C# 解决方案并不适合 Java 中非常自然的解决方案。
Your question is ironic. You're wondering why the Java community is struggling with three different proposals for adding closures, and your suggested solution is to add a fourth option to the mix?
But to answer your question:
The right forum for discussion is the mailing list of openjdk project lambda. This is not a place where suggestions are likely to influence that effort.
The type systems for C# and Java are significantly different, so the C# solution would not directly apply. For example, C# has declaration-site variance (in/out), while java has use-site variance (wildcards). Inference of lambda parameter types as specified in C# would not apply in Java.
The evolution of Java must remain backward compatible, but adding the delegate keyword would be a breaking change.
C# has three types of delegate expressions: the old one with the delegate keyword, statement lambdas with =>{, and expression lambdas. If the C# language team has it to do over again, we'd certainly not have this many forms. Why should Java adopt C#'s historical baggage?
Because C# generics operate over primitives, the Func<> and Action<> delegate types can be used as poor-man's structural function types. But in Java, generics are erased, work only over reference types, and types cannot be distinguished by their arity. Consequently Java would have to have a large number of distinctly-named "standard" function types to get the same effect. That would not be pretty.
Overall, the C# solution does not adapt to a very natural solution in Java.
C# 除了委托之外还有闭包。在我看来，它们并不相同。
委托=函数指针。
闭包= {函数，环境}。
定义[匿名]函数并将其与其环境打包的方式。严格来说，后者只能称为闭包，前者是“lambda 表达式”。
C# has closures in addition to delegates. In my mind they are not same.
delegate = function pointer.
closure = {function, environment}.
Way of defining an [anonymous] function and packaging it with its environment. Strictly speaking latter should only be called closure, the former being 'lambda expression'.