One person in this entire thread is hammering the "copy" notion somewhat heavily, though he did back that up with some real-life examples in other languages, and most importantly is referring to an implementation detail. Stop being so paranoid.
The exact meaning of the word "closure" is of course hotly debated, not properly defined, and especially in regards to working with some obvious and logical constraints that must be adhered to if closures are to be added to java, really a rather nebulous concept. I don't really care how much you keep beating this drum of "My meaning is the only right one and the rest of y'all are engaging in something I find patently absurd" - it's you who is holding absurd notions here. How to add closures to java is not a no-brainer. The meaning of the term "closure" is like most other tech terms bastardized. Welcome to the world. Our languages are living, mutating entities. I suggest you learn to deal with it instead of go off on a rant every time. On Jun 7, 3:26 pm, opinali <[email protected]> wrote: > On 5 jun, 07:15, Reinier Zwitserloot <[email protected]> wrote: > > > Reply inline. > > > On Jun 5, 5:18 am, opinali <[email protected]> wrote: > > > > If you mean the requirement to capture unrestricted variables (not > > > just final ones) > > > It wasn't. > > Ok, that was implied by the context of that email (quoted content > 'heap and avoid the annoying "final limitation". This does not match > Neal Gafter's definition of a closure'). > > Anyway, the debate now drifted to whether capturing a COPY of > variables (or only capture their value) is sufficient. This patently > absurd. Even if we have a new paradigm that favors avoidance of > mutable variables (and I certainly subscribe to this), let's not play > revisionism and redefine a classic, fundamental CS concept that was > cast in stone forty years ago and which exact meaning was crystal- > clear and NEVER debated... before some Java advocates appeared with > nonsensical, bastardized closures. This kind of attitudes - both > avoiding a no-brainer feature like true closures, and doing a half- > assed attempt but claiming that it is a closure - makes Java the > laughing stock of serious programming language designers. Just create > a new term that is not "closure", and assume publicly that Java does > not have closures and will never have closures. It's not like we are > butchering live kitten or something. Well, almost. > > A+ > Osvaldo -- 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.
