On 1 jun, 22:51, Reinier Zwitserloot <[email protected]> wrote:
> Neal Gafter's definition of a closure is miles away from what we're
> getting. Fortunately.
If you mean the requirement to capture unrestricted variables (not
just final ones), this is not "Neal's definition", this is everybody's
definition; it's _the_ formal definition of the closures concept
("function with free variables bound in its lexical environment").
Nobody ever discussed that for decades... until Java appeared with its
brain-damaged inner classes, and started teaching a whole generation
that closures are something complex, dangerous, confusing - unless we
protect stupid programmers with some limitations (which also
contradicts decades of experience with previous and current
languages).
A+
Osvaldo
> NB: The 'final limitation' exists because of confusion. For example,
> what does this print:
>
> Runnable[] r = new Runnable[3];
> for (int i = 0; i < 3; i++) r[i] = #() {System.out.print(i);};
> for (int i = 0; i < 3; i++) r[i].run();
>
> Looks like it ought to print "123", right? Nope. It would print "333".
> Which is confusing. Also, as closures can run anywhere it means local
> variables may need synchronizing. So, should we now also allow
> "volatile" on local variable declarations and abandon one of the few
> last bastions of hope when trying to reason about rocket science
> (read: multi-threading stuff), namely that local variables cannot be
> shared with other threads, ever, and thus never need thinking about in
> regards to locking?
>
> Hence, I fully support at the very least the need to mark such shared
> variables with some marker or other. One suggestion is to actually let
> the compiler do its thing but emit a warning when it does, which can
> be suppressed by adding an @Shared annotation to the local var.
> Another one is that it's not legal java code unless you add either
> "shared" (new context sensitive keyword) or "public" to the local var
> declaration (existing keyword). A final one is that AtomicReference/
> Integer/etc are good enough for any man. I like most of those.
>
> On Jun 1, 8:41 pm, Casper Bang <[email protected]> wrote:
>
>
>
>
>
>
>
> > On Jun 1, 8:04 pm, Alexey Zinger <[email protected]> wrote:
>
> > > 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.
>
> > Yeah that was my conclusion as well; that we will have to continue to
> > put variables into a one-dim array in order to hoist it from stack to
> > heap and avoid the annoying "final limitation". This does not match
> > Neal Gafter's definition of a closure. Or did I misunderstand?
--
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.
