But when you refer to other things which actually *are* closures in ways that suggests that they’re not closures because they’re not anonymous functions, you’re simply wrong and I will correct you.

There’s a lot of places where Groovy does not use “new Foo()” to construct objects. Inline lists, maps, anonymous function, and “as” coercions are far and away the most popular choices. So it’s kinda annoying to have to fall out of succinct code and back to something as chatty as:
new Foo() {
void bar() { … }
void baz() { … }
}

Plus, the @Newify AST transform pushes the distance between Groovy and Java’s “new Foo()” syntax yet further. The whole language is trending away from that stuff.

And yes, programmers conflate “closure” with “anonymous function”. Get used to it — the chance to stop that terminological issue has long past. :P

As to the notion that one should use named classes, this seems… well, not so much an argument as an assertion. And it’s one that doesn’t make any sense to me at all.

Consider the options: I have a class that I want to instantiate exactly once. I can either a) Not name it, put it exactly where it is used and just let it capture the local scope or b) Assign it a meaningless name, figure out somewhere appropriate to put it and manually write code to transfer the state from the local scope over to it. (In the iterator case it doesn’t matter that much because elements doesn’t capture any arguments. But when you want to capture local variables or arguments it quickly gets out of hand).

So, I basically consider “use a named class” not a viable option.

So it comes down to the question of coercing maps vs. instantiating classes. And I simply don’t see the appeal of the map option. It seems unnecessarily magic. Further it doesn’t transition smoothly to more general uses – you end up with a sharp discontinuity between the map of functions syntax and falling back to using a named class. The anonymous inner class plays well with the class and object system, so doesn’t fall down when you hit areas which the magic doesn’t support (I have no idea exactly what these are because I don’t use Groovy. Does Groovy allow interfaces with implementations? Does it have an independent mixin mechanism? If not, can this trick work when returning a class?)

I also don’t understand your point about syntax. I assume groovy writes constructors the Java way: new Foo( ). Thus it seems to make sense to construct other classes in exactly the same way. You could make a distinction for interfaces, but why bother? Doing things one way for classes and one for interfaces seems needlessly confusing.

Finally, I want to take terminological issue with your “Most anonymous inner classes are really closures at heart”. I know what you really mean is “functions”, but actually *all* anonymous inner classes are closures, not at heart but in fact. They capture their defining scope in exactly the same way that a “closure” does, and are implemented the same way.