Closures, too much or too little?

tronicek at fit.cvut.cz tronicek at fit.cvut.cz
Mon Nov 23 07:58:40 PST 2009


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