Re: How do you change all elements in a Collection at the same time?
Daniel Pitts wrote:
True, but what would be the harm in having an interface:
public interface Closure<R, P> {
R execute(P);
}
This already exists.
and a new language feature:
public <T> void methodWhichTakesClosure(Closure<T, T> closure);
...
methodWhichTakesClosure(closure<Integer, Integer>{return arg+1; });
which would be equivalent to:
methodWhichTakesClosure(new Closure<Integer, Integer>() {
Integer execute(Integer arg) {
return arg + 1;
}
});
This just looks like syntactic sugar, much like the enhanced for-loop. If you
think
closure<Integer, Integer> { return arg+1; }
which to my eye lacks any resemblance to a method signature that can be
enforce, is clearer than
new Closure<Integer, Integer>()
{
Integer execute(Integer arg)
{
return arg + 1;
}
}
than I see why you favor it. To me, the latter form is much more explicit and
plenty easy to understand, and leaves less to guess than the first format.
Anything that makes the intention of the calling code clearer is a Good
Thing(TM) in my opinion, and its [sic] just as type safe.
I agree that clearer is better, but not that your closure form is clearer.
While we're adding keywords and language features, maybe a shortcut to
"Runnable" or "Callable" would be a useful idiom as well.
SwingUtilities.invokeLater(runnable{updateGuiWith(results);});
I have the same objections. I cannot tell how the syntax here tells me what
exactly is happening, whereas the "new Runnable() { public void run(){...} }"
syntax reveals all and hides nothing. To me, the existing Java syntax is
clearer, and therefore by our common principle of "clearer is a Good Thing" we
should stick with what we've got.
- Lew