Why not .NET-style delegates rather than closures in Java?_问答_开发者

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 a开发者_运维百科nd 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.

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# 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'.