You mostly get the idea, and I like the demonstration comparing storing state in a class vs. in a closure (”anonymous method” is such a dumb name – I wonder whether this was introduced because it got too difficult to distinguish between .NET 1, .NET 2 and .NET 3 versions of delegates?), and that is a very good way to understand the mechanism, i.e. an alternative method of binding state and action. However, some points:

1. It will be easier, in general, to manage concurrency with closures, than for storing state via class fields, because the “external references” will have been “captured” by the closure, i.e. they can’t change inside the closure. This is not a Delphi-specific thing, and I don’t know if there are plans to put such guarantees or checks in the compiler, or anything like that, but this is how functional programming languages approach concurrency – closures with no side effects. Within methods (object methods), side effects from inside the method scope are not only easy, but even normal (this is the OOP paradigm). You’re very close to seeing the benefit of closures for concurrency with your

mm := TMotile.Execute( procedure; begin end; );

example; now just try to see that the closure you just defined can be *intrinsically* thread-safe, because all the state it needs has been bound and made available at the perfect place . (I don’t know how side-effects are managed in Tiburon, just giving a brief description of the closure-concurrency relationship as it might apply to Delphi)

2. In addition to concurrency, closures are very often used for event programming. For instance, a commonly used example is when, say, you want to remember something during a mouse-down, and recall it during mouse-up (e.g. drag-n-drop). With classes, you would store the data in a field and recall it later, whereas with closures, you write the mouse-up event handler inside the mouse-down event (capture context-specific state too), and assign the method pointer to the mouse-up event slot. Again, two different approaches. Technical merits of each aside, it is informative to think about different ways of doing things. My personal opinion is that this is a far more intuitive and logical means of writing connected events than storing temporary data inside an object instance, but ymmv.

3. I disagree that with closures, anything has been “hidden”, or maybe I fail to understand what you mean (the method name?). I also disagree that closures are “simpler” in some sense. They are simply another method of binding state and action, that’s all.

4. The “with” strawman is not convincing. The problem with “with” is the possibility (indeed, likelihood, in large projects!) of namespace collisions, not the fact that information is hidden, per se. There is no similarity with closures. Again, the fact that the closures do not have names, or that they are called “anonymous methods” in *this* implementation has nothing to do with the functionality -> which is the binding of state and function. “Anonymous methods” is a really dumb name. Almost as dumb as “Lambda expressions”, but at least there is a hint there that something else is going.

5. I disagree that closures should only be used when one *has* to. I would rather promote that closures should be assignable (and used) throughout the Delphi event subsystem. As far as I know, according to Andreano Lanusse and Barry Kelly, this is not (yet) possible. Using closures as events would clean up many class declarations of fields that are simply there to propagate state from one event handler to another.

6. You neglected to mention that Delphi already has a type of “closure”—not the function pointers of your “Cook” example above, but rather nested functions and procedures. However, they are dangerous because they do not *bind* the enclosing scope, i.e. A nested function that refers to local variables in the parent function will continue to use the newly updated values of those local variables throughout the execution path of the parent function. This would be where angels fear to tread.

7. Everyone knows generics and closures are coming to Delphi Win32 because they are required in Delphi.NET which is required to support C#/.NET dynamic features. This is obvious, and a given. That said, some of those features, like closures, might prove worthwhile in spite of their origins. I am less enthusiastic about generics, which, imho is just a typing-saver and is likely to make debugging more difficult. Closures will also make debugging more difficult (where do you set the breakpoint???) but the advantages are a little clearer. At least for me.

On the whole, a good post, and clearly written. I note that you have not outright said “anonymous methods are bad!”, but have rather chosen to require evidence, and this is a good thing.

(I’m probably not going to swing by here and read replies to this comment, unless I get a DelphiFeeds update…)

Cheers
Caleb

So far the only use I can see for anonymous methods is when they are really succinct. For example a sort function that requires a comparison method as argument.

Surely the anonymous method name stems from the fact that the method reference being passed by reference will no longer need to have an identity, i.e. the anonymity apparent (again, or not) from the consumer side of the framework?

Re your PS – I have no doubt that my name isn’t well known in non-tech, although I’m not so sure whether that would count in my favour or against me!

This blog is, in part at least, an attempt to rehabilitate myself in the community.

You ask why we use links in web pages, instead of quoting? When we describe code – we actually do quote for clarity. Without anon.methods, we are forced to “link” to our code (ie refer to some other function), instead of “quoting” what we want to do at the place we want to do it.

P.S. Your name is well known in delphi.non-tech, and I am sure that Dennis Gurock would not have any issues with adding you to the Delphifeeds list. It never hurts to ask

I am supposing that you are offering Ruby as an example where anonymous methods already exist and provide the “real” examples I asked for.

A fair point in it’s way, but if was writing the sort of code that Ruby is useful for, or if Ruby was well suited to the sorts of application I do write, I would already be using Ruby.

So I guess what I am really asking for is “examples that I can see apply to the way I use Delphi and the sort of code I work with”.

I hope to get onto DelphiFeeds at some point, but usually a blog has to have been running for a while (3-6 months) to qualify. I may approach them in a few weeks though to see if my content up to that point is considered good enough to warrant an exemption.

In the meantime, tell your friends.

PS – you should get your blog aggregated by the Delphi Feeds site to allow more people to realise it exists.