Java 7 to get Closures!

[HappyCat]

Cas - you're mad   

You wouldn't be able to make any distinction between the "interface" (which won't change much) and the "workings" (which might change drastically with every release).

Might not matter a jot within your own code, but would make library writing (or even just working in a team) almost impossible, for both the library user ("where's method X gone?") and the library writer ("I need to change that apparently unimportant method prototype, but what if people are using it?").

[CommanderKeith]

The number of times I've been pointlessly thwarted trying to get some feckwitted library to do my bidding but been stuck because some bit of code was protected or private that I wanted to call or override... grr

And it's most annoying that the default accessibility is package-private. It should be public or at least protected.

Interestingly, I read somewhere that one of two things that James Gosling would have changed about java is that he would abolish class to sub-class inheritance and have interfaces only. (The other thing he wished he could do was ditch AWT)

[princec]

Aye, see, I've already got a mechanism to distinguish the workings from the interface, and they're called... interfaces
Turns out AWT is also not so hard to ditch

Cas

Games published by our own members! Check 'em out!

[Roquen]

Interestingly, I read somewhere that one of two things that James Gosling would have changed about java is that he would abolish class to sub-class inheritance and have interfaces only.

Ouch. Seems like a lot of people want SmallTalk with a easier syntax. No wait, SmallTalk has closures...dang!

[HappyCat]

Aye, see, I've already got a mechanism to distinguish the workings from the interface, and they're called... interfaces

Fair enough - hadn't thought of it that way   

[i30817]

Myself, i think interfaces were a mistake.

The real solution is abstract classes ... err... i mean traits.

Predictably there a now a lot of f**kwits on the mailing list fighting against extension methods, without which, lambdas are really f**king useless for the std api.

[swpalmer]

Aye, see, I've already got a mechanism to distinguish the workings from the interface, and they're called... interfaces
Turns out AWT is also not so hard to ditch

Cas

How about everything is protected by default and ONLY the methods that implement an interface are public.  No other methods are allowed to be public.  So if you want to add a public method you have to extend or add an interface that your class implements.

I personally thing protected access is strange the way Java did it.  Allowing any class in the same package to access protected fields seems lame.  There is no way to have fields accessible only to the class and other classes that subclass it *without* allowing access to all classes in the same package.

[Don Kiddick]

My personal take on this, is that the mulitprocessor revolution is coming, or has come. Unless we find some other solution, machines many many processors will be the norm. 2 is the norm now, extrapolating with Moore's law we hit > 200 processors before 2020.

*If* this does happen, our current programming methods with regards to concurrency will not scale. A solution will be found and accepted to this. Currently it seems to be looking like the adaption of ideas from functional programming although there are other ideas abound such as transactional memory. Whatever it is, it will take the headache out of multithreaded programming, either by making it difficult to do unsound things or providing lots of scaffolding to make it easy to do the write thing.

Where would this leave Java? Well there is still going to be huge investment in java lying about. As we've seen with COBOL, it's not going away anytime soon, even if new software will rarely choose it. I see the addition of closures as enhancing the ability of these programs to harness the power of multiprocessing, maybe in just focused performance critical sections. This would allow these programs to live and breathe a lot longer.

I totally understand the problems of bolting on features to the language. Generics are a case in point - I think we can all appreciate the good and the bad of them.

So, there's no easy answer. I think for me, maybe it's too early. Servers with massive numbers of processors are not yet the norm and it even remains to be seen whether they will be. Maybe we will work out another solution to the problem. Maybe it should be java 8?

Happy Christmas,
D.

[Roquen]

Transaction memory attacks a completely different problem: communication between threads, processes, etc. and is a logical entension of load-link/store-conditional operations.

IHMO, there is no reasonable single way to address all types of concurrent computation: threads, OpenCL/CUDA/Shaders, continuations, and a proper closure all attack different needs.

[Mordan]

I agree with the simplicity argument but Java needs closures/lambda expressions.

Writing programs would be more readable and elegant. For those who don't really understand. A Method is an Object without the overhead. Defining a class for all your functions is inefficient. Plus anonymes classes are ugly and not byte code efficient.

I have implemented my own little lambda (100+ functions) framework for J2ME because of the class size overhead is relatively huge.