Closures, too much or too little?

[tronicek at fit.cvut.cz]

Hi Reinier,

you are asking for logical arguments where there are rarely any.
Design of a new language feature (or a new language) is always a matter of
taste. For example, if I propose to extend operator = for array so that
int[] p = []42; initializes all the elements to 42, will you find any
"pragmatic argument" against?
We can discuss if it useful or not. Then Josh may say "yeah, we need it!
we have many arrays at Google", Joseph "I like the for loop more" and
Howard may ask for annotation @Expensive. And you, as a designer, you
either like it or not. But "pragmatic arguments" against?

Z.
-- 
Zdenek Tronicek
FIT CTU in Prague
http://kenai.com/projects/refactoringng - refactoring tool for compiler guys


Reinier Zwitserloot napsal(a):
> auto-final can be combined with @Shared (with @Shared being one option
> when
> you access a mutating variable from outer scope), though once auto-final
> is
> in place, I don't think @Shared is a make-or-break kind of issue with
> closures.
>
>
> As mark mentioned, it DOES happen though (probably will happen a lot more,
> when closures are added in JDK7), and people use a number of different
> solutions to get around this. This is a bad thing. I've seen arrays, I've
> seen AtomicReference and friends, and I've seen hand-rolled Pointer
> classes.
> I've even used all 3, though I've standardized myself on always using an
> Atomic* for it, whether or not I actually need the atomicity.
>
> Is there any pragmatic argument AGAINST adding @Shared to the language,
> other than "Any feature should prove why we have to add it, not why we
> shouldn't", and hazy concerns about keywordishness, which seems like a
> taste
> fight, not an actual discussion, not to mention solvable by replacing
> "@Shared" with public.
>
> My personal preference lies in auto-final *AND* @Shared.
>
> --Reinier Zwitserloot
>
> On Mon, Nov 23, 2009 at 5:18 PM, Joshua Bloch <jjb at google.com> wrote:
>
>> 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.
>> > >
>> >
>> >
>> >
>>
>>
>
>