On 13 Set, 09:51, Fabrizio Giudici <[email protected]> wrote: > I won't dare to enter the ground of interpreting what's a closure > because I'd get it wrong. But I think that the following statements are > true: > > 1. "foobar" is a language construct that either is the same thing of a > closure or a subset of a closure > 2. foobars are useful for programmers > 3. the difference between a foobar and a closure, if any, is neglectable > from a practical point of view > 4. Java has always had foobars, in form of SAM classes > 5. Java 8 provides a nicer, shorter syntax for foobars > > I think that points 1, 2, 4, and 5 are quite obvious and I suppose > nobody disagrees. So, the important point is #3. If you can't > demonstrate that point #3 is false, then clay and C dric might be not > pedantic enough from a semantic point of view (not my business), but are > substantially right.
Well, a practical point of view depends on what, in practice, you want to achieve ;) I think that for the typical usage of inner classes in Java, there's no practical difference. Still, as soon as you step out of typical use patterns, you can be bitten if you don't know the rules. In detail, a closure is a function that captures the entire lexical environment it's defined in. If we gloss over the fact that Java has no functions, and we treat instance methods as if they were functions [*], we still have that Java methods are not closures because they capture only a part of their surrounding lexical environment, that is, final local variables. Note that: - whether loop variables are implemented with one binding per iteration vs one binding per loop + assignment (the capture in the for loop example presented upthread) is orthogonal to closures. - whether the language supports anonymous functions (lambdas) is orthogonal as well. - mutability of captured variables is not a requirement for closures in general, but it is *in languages that have mutable variables* like Java, because the captured environment inside the closure must be indistinguishable from the one outside. - mutable captured locals are a key feature to implement lightweight prototype-based object systems in non-OO languages (such as Scheme and Lisps before Common Lisp) but that's irrelevant in Java. - mutable captured locals (in languages with mutable local variables) are a key feature to implement closure-based control abstractions. This is not that irrelevant in Java. Still, control abstractions need to capture more than just variables, see below. - lexical environment is not just local variables, it's everything reachable lexically, such as labels and surrounding loops (for break and continue). The return statement is peculiar because it can be argued that it must refer to the lexically enclosing method or to the lambda itself, and both have pros and cons. In Lisp return refers to the lexically enclosing block, but in Lisp return is not typically used to return a value from a function (the value of the last expression is automatically returned), so this is not a concern in practice. In Java it's much more debatable. Exception handlers, instead, are dynamically bound, so they are out of the question. To summarize: for the average developer, anonymous inner classes in Java are closures. He will sometimes be bitten by them not capturing something he thought they would, but that's hardly a problem, especially with modern IDEs. With respect to the advancement of the language, and for framework writers, anonymous inner classes are not really closures, but in practice that's a minor nuisance. Java has far worse problems than lack of closures. Peace, Alessio [*] generally they're not, because they're not first-class, but in the special case of SAM types, it's indeed possible to use the SAM instance as a method reference. -- 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.
