Closures, too much or too little?

Joshua Bloch jjb at google.com
Mon Nov 23 08:18:00 PST 2009


I'm still not convinced that it's a good idea to allow closure to capture
shared local variables.  I do (still) like the idea of "auto-finalization"
(i.e., it's OK for a closure or anonymous class instance creation
expression) to reference a local variable that's not explicitly labeled
final if DU/DA-style analysis shows it to be effectively final.  I suspect
this is the sweet spot.

             Josh

On Mon, Nov 23, 2009 at 7:58 AM, <tronicek at fit.cvut.cz> wrote:

> Hi Howard,
>
> you can argue similarly for example in case of method overriding and
> overloading and suggest to add the "override" and "overload" keywords. I
> do not mind if the "shared" or "public" keyword is mandatory in this case.
> However, mandatory annotation is odd for me.
>
> Z.
> --
> Zdenek Tronicek
> FIT CTU in Prague
> http://kenai.com/projects/refactoringng - refactoring tool for compiler
> guys
>
>
> Howard Lovatt napsal(a):
> > Hi Zdenek,
> >
> > The following example from Josh Bloch illustrates why I would rather
> > writable captured variables generate an error if you miss off @Shared:
> >
> > public class Test {
> >
> >     private static final int N = 10;
> >
> >     public static void main(String[] args) {
> >
> >         List<{ => int}> closures = new ArrayList<{ => int}>();
> >
> >         for (int i = 0; i < N; i++)
> >
> >             closures.add( { => i } );
> >
> >         int total = 0;
> >
> >         for ({ => int} closure : closures)
> >
> >             total += closure.invoke();
> >
> >         System.out.println(total);
> >
> >     }
> >
> > }
> >
> > This example is almost certainly an error; therefore I feel a warning is
> > insufficient, much like "int i = 2.0;" is almost certainly an error and I
> > would find a warning insufficient for this too. To me the warnings that
> > are
> > in Java currently are all dubious; they are just a fudge because of some
> > other problem, e.g. erasure.
> >
> > With regard to annotations, if people really like the concept that an
> > annotation should not be like a keyword then make shared a keyword (I am
> > happy either way). I think Josh Bloch has suggested reusing public, but I
> > would prefer either shared or @Shared.
> >
> >  -- Howard.
> >
>
>
>



More information about the coin-dev mailing list