Closures, too much or too little?

[Howard Lovatt]

I would support @Shared either as a keyword of annotation to be adding to
the whole language so that the current inner classes and any new inner
class/closure construct could use it. I wouldn't support adding @Shared just
for a new construct and not including current inner classes. As for
auto-final, no strong feelings (I almost exclusively use final anyway).

 -- Howard.

2009/11/23 Reinier Zwitserloot <reinier at zwitserloot.com>

> 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.
>> > >
>> >
>> >
>> >
>>
>>
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
>



-- 
 -- Howard.