There's ongoing discussion about a keyword to mark a variable as heap-
hosted. Also, if you're using 1-dim arrays you're doing it wrong. Use
AtomicReference/AtomicInteger/AtomicDouble/etcetera instead.
Neal Gafter's definition of a closure is miles away from what we're
getting. Fortunately.
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.
