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 msft-styled 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 SQL, 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.
