Why are “anonymous methods” called “anonymous”?

You can take a look here [http://barrkel.blogspot.com/2008/07/anonymous-method-details.html] where Barry Kelly (the compiler guy that was behind Delphi a.m. implementation) detailed some interesting facts about a.m. (closures)

… a more “friendly” link to the Barry blog entry: http://barrkel.blogspot.com/2008/07/anonymous-method-details.html

The concept isn’t the difficult thing to grasp.

aiui - An invisible class with a single method… funny thing, we’ve have the ability to do that all along. I don’t see code littered with these things that can now be dispensed with thanks to higher level support in the language.

Practical applications that will not have dire consequences for future maintenance - that’s the thing that is decidedly non-obvious.

I could develop a device that enables two materials to be combined to create an explosive chain reaction.

It’s usefulness lies principally in being an essential component in the building of an atomic weapon.

The question then is, other than that use, does it have any intrinsic value as a device, and if not, the question then has to be not is the device itself of any value, but are atomic weapons of value.

OK, so that’s an extreme an hyperbolic example, but is only to illustrate my problem with something that has no easily explained or apparently obvious intrinsic value in and of itself.

If the ONLY real use of closures is in facilitating LINQ, then why bother exploring closures too closely? Just concentrate on LINQ and leave the untidy implementation details alone.

The problem there is that LINQ itself has a very narrow field in which it is of practical benefit/desirable, which leaves the uncomfortable feeling that a lot of time and energy has gone into something which isn’t going to deliver the returns it was perhaps thought. Which won’t stop the originators from PROMISING that such returns MIGHT be gained.

It all reeks of software snake oil.

Having said that, Barry Kelly has promised to provide some concrete examples that will hopefully lead to a personal epiphany in the field.

Here’s hoping….

The thing with anonymous methods is that their anonymity isn’t what makes them so useful. What makes them a big deal is that they can be defined in-line where they’re used, they carry along the scopes of their callers, and they can be called from places other than the scope where they’re defined. (Without that last bit, they’d pretty much just be nested functions.)

Being anonymous really just means that they’re hard to call recursively. (Although it’s not necessarily impossible. All we’d need is a “fix” function.)

Part of what will determine anonymous methods’ usefulness will depend on how much of the VCL and RTL are retrofitted to accept the new “reference to” methods instead of plain function pointers. The common example is CustomSort. If you want to sort a list of objects based on a run-time-configurable field of the class, it can be hard or cumbersome because the TListSortCompare type doesn’t accept any parameters other than the items to be compared, and it must be a standalone function, not a method. Options are to have a global variable that gives the sort criterion, have separate comparison functions for each possible criterion, or write a separate sorting routine that accepts a more versatile comparison function.

It’s true that we’ve always been able to declare classes of our own, give them fields and a method that uses those fields, instantiate the class, assign all the fields, call the method, and then free the object. But now we don’t have to do all that. We can just write the method and call it. No more object management, and no need for tiny utility classes.

We don’t need anonymous methods because we’ve always been able to do the same thing ourselves; anonymous methods are ultimately just syntactic sugar. But so are interfaces: We’ve always been able to declare records of function pointers, initialize their fields, and implement stub functions that redirect to methods of a class. But when the compiler assists by doing all that for us, interfaces are much easier to create and consume. We didn’t really need language support for Variants, either. We could have assigned the type and data fields and called all the conversion functions ourselves.