So basically, this is just syntax sugar around single-method anonymous inner classes. I'm not saying it's the end of the world, but they aren't closures strictly speaking. Everything I ever read about what differentiates closures from anonymous inner classes (control flow, lexical scoping) is untouched as compared to what we do already with more verbose syntax.
Alexey 2001 Honda CBR600F4i (CCS) 2002 Suzuki Bandit 1200S 1992 Kawasaki EX500 http://azinger.blogspot.com http://bsheet.sourceforge.net http://wcollage.sourceforge.net ________________________________ From: Reinier Zwitserloot <[email protected]> To: The Java Posse <[email protected]> Sent: Mon, May 31, 2010 6:08:52 AM Subject: [The Java Posse] Re: Good gosh J7 lambdas/closures are looking worse by the day Here's a very short rundown on the official syntax, with a link to the last known proposal at the end. The current status quo isn't, as far as I know, 100% the same as the 'official' proposal, because a new version of the spec hasn't been released in months. There's also been an encyclopedia's worth of traffic on concerns and disadvantages on lambda-dev, but none of those have been discussed by Mark Reinhold, Alex Buckley, Maurizio Cimadamore, or Brian Goetz, who all seem to be involved in writing specs and implementations. closures themselves come in two flavours. Either form is an expression, whose type is a closure type: inline expression form: #(parameter list) ( expression ) block form: #(parameter list) { any number of statements; } The first form is syntax sugar for: #(parameter list) { return expression; } So, you can write: Object plusClosure = #(int a, int b) (a+b); which is the same thing as writing: Object plusClosureLongForm = #(int a, int b) {return a + b;}; [Justification: In practice blocks have to be written in standard style, so, line breaks after opening brace and before closing brace, lest it look like a semi-colon party, but that means all closures are multi-line, even very simple ones, such as plus, so, there's a short- hand form if you can express the body of a closure as a single expression. Also, inferring parameters is essentially impossible but inferring return type and checked exceptions isn't, and closures should be simple (and syntactically very brief), hence the inference.] Note that 'long returns' doesn't work, you can't break or continue a loop that your closure definition is in, nor can you return from the method that your closure definition is in. Also, the closure captures all variables from outer scope but you can't actually interact with them unless they are final or effectively final (effectively final = not marked final, but wouldn't cause an error if they were marked as such). The full type signature of a closure consists of 3 properties: A) Parameter List. Read from the actual parameter list in the closure definition. B) Return Type. Inferred from the return statement (block form) or the type of the expression (inline expression form) C) (checked) throwables thrown. Inferred. Obviously assigning a closure to an "Object" variable isn't very useful. There are two useful type concepts you can assign them to, function types and SAMs. Function Types. These look like this: #int(int, int)(throws IOException | SQLException) plusClosure = #(int a, int b) (a+b); [yes, good lord, that's some horrible syntax, I know - also the official 1.5 spec on function syntax is riddled with errors particular in regards to the throws syntax; alternatives that also might be valid depending on where you look in the spec is "(throws IOException, SQLException)" and just "(IOException, SQLException)". justification: Without the extra parens around the throws clause the parsing rule wouldn't terminate which isn't legal in LL(k) grammars such as the ones used by most java parsers including javac. Or something. I was a bit fuzzy on this, you may want to check lambda- dev.] function types can be 'executed' by using the dot. For example: assert 15 == plusClosure.(5, 10); [justification: In java, method names and variable names are separate namespaces, so just closureVarName() would be looking in the wrong namespace!] Closures can also be assigned to SAM types. A SAM type is any type that is (1) abstract and (2) has only one undefined method in it. In other words, any interface that mentions only 1 method, and any abstract class where all but 1 method has an implementation. Like FileFilter and Runnable. Thus, this would work just fine: Runnable r = #() {System.out.println("Hello, World!");}; r.run(); //Will say hi to world. r.(); //This wouldn't be legal; r is a Runnable, not a #()(). The mechanics for realizing that the above closure declaration, which is of type #()(), can be 'fitted' safely into a java.lang.Runnable SAM, requires lots of complex inference rules. This inference includes the reasoning that returning something is compatible with returning nothing, an inference that doesn't occur anywhere else in java. E.g: #void(Integer a) = #(Number a) (a); is legal. If you throw enough generics in the mix, the errors are going to balloon into gobbledygook. Nevertheless, SAMs are what today's java libraries run on, so any closure proposal that cannot 'autobox' themselves into a SAM type would be even worse. "this" in a closure refers to the closure object. This seems nuts but has been added for the benefit of allowing closures to recurse into themselves. However, you'd get an endless loop when trying to infer return type if you actually returned 'this', so the following is explicitly defined as a compiler error: Object closure = #() (this); //Infer the return type on this miracle! The actual way closure types are created most likely will involve generics of some sort, so arrays of closure types, like so: #()[] = new #()[10]; aren't legal for the same reason you can't write new T[10]; Link: http://mail.openjdk.java.net/pipermail/lambda-dev/attachments/20100212/af8d2cc5/attachment-0001.txt On May 31, 8:07 am, Mark Derricutt <[email protected]> wrote: > I realllllly don't like the look of them. If they'd reused { } around the > actual method call I'd be much happier. But reusing ()? > > -- > Pull me down under... > > On Mon, May 31, 2010 at 5:58 PM, Michael Neale <[email protected]>wrote: > > > > > > >http://www.baptiste-wicht.com/2010/05/oracle-pushes-a-first-version-o... > > > I guess most of the attention has been on the semantics (and rightly > > so) but wow... just wow. > > > (sorry to interupt the appleposse with java news). > > > -- > > You received this message because you are subscribed to the Google Groups > > "The Java Posse" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]<javaposse%2bunsubscr...@googlegroups > > .com> > > . > > For more options, visit this group at > >http://groups.google.com/group/javaposse?hl=en. -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en. -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
