Closures, too much or too little?

[Reinier Zwitserloot]

Plenty of pragmatic counter arguments to your hypothetical:

1. It looks confusing. Testable empirically by showing random programmers
off the street "int[] p = []42;" and asking them if they have any idea about
what that could possibly do.

2. It's meaningless; arrays in java need a size, and = assigns a new one to
the left hand side, so where's the total capacity of this thing? I presume
you meant to write "int[] p = new [100]42; instead.

3. A search through existing code bases will probably reveal initializing an
array with the same value throughout is a rather rare thing to do. Thus, the
above code would rarely be used, which doesn't just mean it's a bad value
for effort deal, but also that many programmers will be stymied when they do
see this code somewhere. See C# Coalesce operator, which about 80% of all C#
coders I interview don't know about.

4. A library can easily do this. In fact, a library already does:
Arrays.fill!


That's 4 pragmatic arguments. So, lets keep pushing for pragmatic arguments.
They clearly exist. On the topic of taste: Yes, taste happens. But please
recognize when you have a taste preference, and just say so: "I like using
FOO as syntax here. Personal taste." - don't try to dress it up. I know most
of us fail to live up to this standard, myself included, but I at least will
endeavour to more rigidly apply this principle.


--Reinier Zwitserloot



On Mon, Nov 23, 2009 at 9:38 PM, <tronicek at fit.cvut.cz> wrote:

> 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.
> >> > >
> >> >
> >> >
> >> >
> >>
> >>
> >
> >
>
>