I got the impression from Dick's note on the closure debate, as well as the response from the black hat guy, that there's some confusion about the closure debates. Yes, that's plural.
There's the: "Should Java have closures" debate. This debate is basically over. Mark Reinhold wants it, and convinced enough people within sun (before the oracle take-over). I doubt this will be back- pedalled now. There's also the: What should it LOOK LIKE debate. This is a complex debate that hits on a gigantic amount of issues, simply because there are a bajillion ways to fit the following requirement set, and not one of them is the obvious right answer: 1) Make it simple to write block-like constructs in java (simpler than it is now, at any rate) 2) Make sure whatever construct you come up with makes Parallel Arrays nice too (required use case) 3) Make sure whatever syntax you come up with is invalid if compiled with javac 1.6, and that anything written for javac 1.6 does not change in meaning. (backwards compatibility) There are a bunch of issues which simply have no clear answer, so the debate on all of these is long, complicated, and involves massive introspection of existing java code as well as example "future" java code to see which makes for the better choice. The list is pretty much endless, so I'll just raise some of the major ones: 1) The 'strawman' of Reinhold at Devoxx allowed something like "Closure foo = whatever; foo();" however, in java, unlike just about every other language with closures, methods and variables are separate namespaces. The above is mixing and matching them; "foo();" currently means: Invoke a method named 'foo'. It does not mean: Do something to a variable named foo. Should we break the separate namespace rule to make closures look more natural (but with a bevy of java puzzlers for when you have methods named foo as well as closure vars named foo - especially because of backwards compatibility), or should we move away form the strawman and use for example foo.invoke() or some other operator such as foo#() to 'run' a closure? Anyone who thinks there's a clear right answer to this is delusional. In practice there's an unclear right answer which is to move away from the strawman, as the effects of making 'someClosure();' work are quite large, and this is in fact the current status quo. The specific syntax for now is: "foo. ();" 2) What should they look like? The strawman seems clear enough but has its problems when you nest closure types in closure types (param type of a closure is itself a closure) especially if some of the involved closure types throw exceptions. There's also some risk that 1 minor typo results in a baffling error message, as closure type declarations and closure block declarations look very very similar in the strawman. A lot of the discussion back in the BGGA / FCM / CICE days was in fact all about what it looks like, e.g. "I don't like the => thing in BGGA". 3) How should it be implemented? Reifying the closure types is virtually impossible, as any closure proposal ought to work well with generics, which aren't reified, and there's no room in the agenda to try to reify generics. But without reified closure types, having arrays-of-closures becomes pretty much impossible, and you get the same erasure problems that generics have. There's some discussion on whether or not a form of reification can be added, though the conclusion so far seems to be: No. However, if reification isn't feasible, should closure types be added at all? The CICE proposal makes do without them. For ease of use with existing code, closure types will auto-convert themselves to "single-abstract-method interfaces" already, so with that feature, perhaps closure types aren't needed. Then again that gets annoying with very functionally oriented libraries. What to do, what to do ? 4) There's also continued debate about time vs. completeness. Certain proposals are way more involved and are basically shot down due to lack of time, but those same proposals do seem to lead to better syntax and a more consistent language, though whether or not this is really true once such a proposal has been fully fleshed out is unclear, partly because there's not enough time to research it. Should java just get closures now, period, even if it won't be as good as it might have been, or should java either delay the release of java7 or move closures up to java8 to provide the time to get to the best possible proposal? -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javapo...@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
