Java 7 to get Closures!

General Discussions
#141

If I designed a language, I’d make blocks be function literals, a proper function type with named arguments, and function type inference.

Then you could write this:

public class Frame {
    public Function(int x, int y) onMouseClicked = null;
}

// Using default argument names
myFrame.onMouseClicked = {System.out.println("You clicked at "+x+", "+y)};

// OR:

// Renaming the arguments (could just rename the first argument if wanted, but have to rename them in order)
myFrame.onMouseClicked = (Function(int r, int n)){System.out.println("You clicked at "+r+", "+n)};

Function(int i) print = { System.out.println(i) };
for (int i=0; i<10; i++) print(i);

Of course, there are millions of potential problems with this. :wink:

But at least it LOOKS CLEAN.

HINT, HINT

#142

If you want clean syntax for functions as first class types then look at languages which were designed from the start to be functional*. SML or Haskell, say.

  • But not LISP. Later functional languages were able to learn from it.
#143

Yes, I agree. My point is kinda that one shouldn’t try to force broken implementations into a language. If you want some feature, redesign the language or move on to another one.

Visual Basic was pathetic. Java’s working hard on getting there.

The JVM is super good and works really well, but I feel like java as a language is starting to fail.
Either leave it alone, or redesign it. Don’t tack things on.

#144

I just want BASIC, with classes and structs :slight_smile: And the total removal of public, protected, and private modifiers! But then, I’m a rebel.

Cas :slight_smile:

#145

:persecutioncomplex: I suppose there is always the Eiffel model of specifying precisely which classes have visibility of each member…

#146

Nah, I just say - if it can be seen on the client, then it can be decompiled, ergo the source is visible, ergo there is no “hiding”. So it may as well all be public. I think the entire concept of encapsulation has just been a huge, massive, mistake, and maybe we’re just beginning to figure this out.

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

Cas :slight_smile:

#147

It is nice, however, to at least know what is supposed to be private and what isn’t. And if you use setter methods instead of directly changing a variable you can have a lot more control when debugging (if something goes wrong with that variable, you can just put a breakpoint in the setter and see who called it).

#148

@princec:
I’d have to disagree on that one.
Even with the current implementation, people do not abide to even the simplest systems and regulations.

At work we had a discussion about the way the OSGI framework allows the explicit declaration of public interfaces and that then only those can be used.
Then these are only visible in the IDE.
Now I won’t use an entire framework just for one feature for an IDE/other OSGI components that otherwise would have any influence, but it would be a REALLY good feature in Java.
Plus a lot of stuff mentioned in the Practical API Design book.

#149

Maybe access to protected/default/private fields/methods would result in a compile time warning (automatically making the actual field/method public in bytecode).

Ok, you can start roundhouse kicking me

#150

I’m just erring more and more towards the “scripting” style of coding. Y’know, where the compiler helps figure out what you want to do, rather than stops you from doing it.

Cas :slight_smile:

#151

Cas - you’re mad ;D

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?”).

#152

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)

#153

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

Cas :slight_smile:

#154

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

#155

Fair enough - hadn’t thought of it that way :slight_smile:

#156

Myself, i think interfaces were a mistake.

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

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

#157

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.

#158

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.

#159

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.

#160

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.