I dunno. I think the python case pretty clearly shows that letting 'variable capture' mean: 'value only', which the python version is more or less close to (though, technically, as you showed with your example where the closure captures an outer in read-only mode by mutating the outer and showing the effect in the closure) - is going to be hopelessly confusing. Folks expect something that looks like the same variable (as in: Declared only once, used in two places) to be _the same variable_, and not secretly 2 variables that are one-way synced up, once, at the _definition_ of the closure.
Regardless of what makes the most sense, absolutely no proposals for project lambda in regards to how to handle capturing variables involves capturing copies (unless said variable is final, in which case as I mentioned before, the difference is simply irrelevant). On Jun 5, 3:37 pm, B Smith-Mannschott <[email protected]> wrote: > On Sat, Jun 5, 2010 at 12:42, Reinier Zwitserloot <[email protected]> wrote: > > On Jun 5, 10:57 am, B Smith-Mannschott <[email protected]> wrote: > >> I suspect that if Java didn't require final i, the results would still > >> be the same, because the implementation would still be forced to copy > >> values into compiler-generated fields of the inner Runnable() class on > >> allocation. > > [ ... snip ... ] > > >> What *exactly* is the closure capturing? The > >> *variable* or the variable's *value*? > > > The variable itself, not the value. Period. Always. In any language, > > or they're abusing the term "closure" even more than java already > > does. Java, to be precise, has never strayed from this definition > > either, and is not going to. Right now it doesn't really matter > > because java's reaction to capturing a non-final variable is always: > > Make it final first. And for final variables, the distinction between > > capturing the variable and its value is moot. > > Good analysis. I guess where we differ is that I'm willing to accept > closures which copy only the values as sufficient. There are two > reasons for this: > > (1) I'm getting away from mutable state in my programming anyway, and > as you point out the two approaches are indistinguishable when > variables are immutable. So, I'm not losing much by having closures > that copy values rather than capture variables. > > (2) In my experience having closures capture mutable variables is > mostly useful for simulating stateful objects (e.g. doing OOP in > Scheme), but in Java we don't need to simulate objects and classes > using closures. > > p.s. For those who haven't read it, there's a cute little koan about > the equivalence of objects and closures (in the full > variable-capturing sense) at the end of the post linked below: > > http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg03277.html -- 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.
