标签云

微信群

扫码加入我们

WeChat QR Code

I've been reading a lot lately about the next release of Java possibly supporting closures. I feel like I have a pretty firm grasp on what closures are, but I can't think of a solid example of how they would make an Object-Oriented language "better". Can anyone give me a specific use-case where a closure would be needed (or even preferred)?


+2 if i could. This is the 'missing link' in discussions about java closures. Deserves a question of it's own, Rainer.

2018年08月16日10分36秒

This is the best description of a closure that I have encountered. I understand now why the new closure implementation is being limited to local only. Danger Will Robinson, Danger!

2018年08月17日10分36秒

+1 Now I understand why Joshua Bloch says Java already has closures ( in the form of anonymous inner classes ) After reading what you said, I agree. The problems with a.i.c is they are way to verbose.

2018年08月17日10分36秒

How does one perform type safety with a closure? Surly an abstract anonymous class is clearer than a closure?

2018年08月16日10分36秒

-1: "They don't make an Object-Oriented language better. They make practical languages more practical.": I strongly disagree with this principle. Maybe closures will make Java more practical, but in principle one should not sacrifice the coherence of a language just to make it "more practical". IMO there must be another, stronger motivation for introducing closures. A language that has a very heterogeneous semantics and a lot of special cases just to be "more practical" is more difficult to learn. Programming languages should be based on concepts not on idioms.

2018年08月16日10分36秒

Thanks for reinforcing my suspicion that closures would just be syntactic sugar for anonymous inner classes.

2018年08月17日10分36秒

If they were as complete as JavaScript/C#/C++0x closures, they would be more powerful than anonymous inner classes, because they would be able to capture modifiable references to local variables, not just readonly copies of finals.

2018年08月17日10分36秒

Daniel Earwicker: You can simulate this by wrapping the modifiable variable in a container object (putting it on the heap) which is then assigned to a local final var.

2018年08月16日10分36秒

Bart van Heukelom - you can indeed, or even better, you can use a language that does this for you! :)

2018年08月17日10分36秒

Bill: Closures are NOT the same as anonymous functions or inner classes, though the differences are subtle. See en.wikipedia.org/wiki/Closure_%28computer_science%29

2018年08月16日10分36秒

Agreed, just for convenient map/filter implementations it would be worth it. Not to mention most uses of anonymous inner classes. Readability and code size counts.

2018年08月16日10分36秒

Upvoted for knowing (and explaining) the distinction between closures and functions as values

2018年08月17日10分36秒

note that the difference is much smaller when you use anonymous classes

2018年08月16日10分36秒

Michael Borgwardt, note that the difference is much more bigger when you have allot of closures and composition of functions.

2018年08月16日10分36秒

good explanation!

2018年08月16日10分36秒

+1 for showing they are syntactic sugar

2018年08月16日10分36秒

I think "spell everything out the long way" would be more accurate as "spell everything out explicitly" (at least in my case). There is a subtle difference.

2018年08月16日10分36秒

Well - I'd say the two are distinct cases with a large intersection. So perhaps if we talk of the union of those two we get to the knub of it :-)

2018年08月16日10分36秒

First-class functions are a distinct idea from closures. The former refers to treating a reference to a function (or the function itself) as a value -- one that can be passed around and invoked at will. The latter is concerned with capturing references to values available lexically at the point of definition and extending their lifetime through the lifetime of the function created there. One can have first-class functions without having closures, though I don't think the converse makes sense.

2018年08月17日10分36秒

Well, they are distinct ideas, but one is based on the other (hence the lack of transitivity in your final comment). I said that, "Closures promote the concept of the function-as-object to a first class entity" - not that they were the same thing. The fact is, as it stands, Java does not have a proper concept of first class functions, but if it got Closures it would get that too as a pre-requisite. That's really what I meant. But if that wasn't clear it's good that you've clarified it with your comment :-)

2018年08月16日10分36秒

When you raise the level of abstraction you are introducing new semantics not just using syntactic sugar. Java is not syntactic sugar over assembly.

2018年08月17日10分36秒

This doesn't answer the question, but +1 for your suggestions! Personally, I do use Scala, and its functional programming is great.

2018年08月17日10分36秒

Thanks for the suggestion and the vote. Maybe I should have made my statement more explicit: I think that Java does not need closures and that this extension will make the language unnecessarily complex.

2018年08月17日10分36秒

I think you are right about that. I think that Java never had functions as objects because Sun didn't want it like C's function pointers (or so I read in Core Java 2). However, there are ways of implementing functions as objects that do not involve function pointers. Again, Scala is the best example of that.

2018年08月16日10分36秒

I just bought my Scala book, staring to read it and I like it a lot! Definitely, I think one should not fumble around with a language like Java or C++, which were not designed to support FP. Java remains one of my favourite language, but if one wants OOP + FP one should look at a language that was designed for that.

2018年08月17日10分36秒

Lexical scoping and Variable Capture from The State of Lambda are great reads; but "effective final", IMHO, is not such a good idea, the compiler probably needs an extra pass to determine "effective finality" and also code that compiles today starts breaking tomorrow b ecause a newly coded line "miles" away from the closure converted the reference to mutable.

2018年08月16日10分36秒

UstamanSangat My understanding is that all free variables in a closure, in Java, are effectively final whether you declare them explicitly or not. I have not read the translation strategy in a while, so I do not know if this is just a compiler thing or if it is instrumented in the JVM somehow.

2018年08月17日10分36秒

Agreed, my point was mostly about a new line of code 20 lines away from the closure changing a previously effectively final variable to a mutable one. When that code doesn't compile, a less sophisticated developer might get confused. But I think an IDE can always help.

2018年08月16日10分36秒

By "abstract class" you mean aonymous inner class?

2018年08月16日10分36秒

I think this is the proposal you're referring to. docs.google.com/Doc.aspx?id=k73_1ggr36h

2018年08月16日10分36秒

yes, Tom - I do mean that - sorry And that looks like it Bill - thanks

2018年08月16日10分36秒

Just to be clear, my question wasn't intended to argue in favor of blocking the inclusion of closures. Also, I would have agreed with the "non-essential" argument for one of the features you mentioned above. :)

2018年08月17日10分36秒

Many features are not essential. However, IMHO one should look at how often a feature is going to be used compared to the complexity it adds to the language semantics and tools.

2018年08月17日10分36秒

It is the first link return by google search for java closure example

2018年08月16日10分36秒

Are you speaking from experience? My experience has been exactly the opposite.

2018年08月16日10分36秒

Edwin Dolarzo's links are great to read. Need to know what approach are already taken by Scala and Groovy and others

2018年08月16日10分36秒