Too terse and too alien?

[Neal Gafter]

On Tue, Jun 1, 2010 at 3:19 PM, Alessio Stalla <alessiostalla at gmail.com>wrote:

> On Tue, Jun 1, 2010 at 11:38 PM, Neal Gafter <neal at gafter.com> wrote:
> > On Tue, Jun 1, 2010 at 2:26 PM, Alessio Stalla <alessiostalla at gmail.com>
> >> Are those aggregate operations expected to be usually limited to
> >> simple math, assignments, ternary ifs and method calls with no
> >> try-catch, switch, loops?
> >
> > In my experience, yes, virtually always.
>
> Really? I forgot to mention no local variables, since Java doesn't have
> let.
> I can come up with reasonable counterexamples:
>

Reasonable, perhaps, but in my experience they hardly ever occur.

sorting people by surname and name (middle name omitted for brevity :D):
>
> Collections.sort(people, #(Person p, Person q) (
>  p.getSurname().compareTo(q.getSurname()) != 0 ?
>  p.getSurname().compareTo(q.getSurname()) :
>  p.getName().compareTo(q.getName()) ));
>

You should probably be using an explicit comparator object here.  This is
likely not the only place in your code base where Person is handled and name
surname/name comparisons are done.

processing all event handlers in a list:
>
> Collections.map(list, #(EventListener e) {
>  try { e.handle(event); } catch(Exception e) { log.error("Exception
> while processing listener", e); }
> });
>

Won't compile.  map() is the wrong operation, as there is no returned
value.  (You're not even using "return")


> accessing non-thread-safe objects in a collection:
>
> Collections.map(list, #(Object o) {
>  synchronized(o) {
>    return o.something(...);
>  }
> });
>

Very dangerous mix of concurrency strategies.  I hope you don't expect to do
this routinely.


> etc. these are really just simple examples.
>

And contrived.  I've worked with thousands of lines of concurrent-aggregate
code and haven't seen much of this.