Comments on: Understanding Anonymous Methods

By: Nick Hodges » Blog Archive » Tiburon News, Information, and Sneak Peeks

Fri, 08 Aug 2008 15:31:48 +0000

[...] Craig Stuntz is talking about Generics and Anonymous Methods. [...]

By: Craig Stuntz

Craig Stuntz — Tue, 05 Aug 2008 15:17:22 +0000

Lars,

One place to look for examples of using anonymous methods is JavaScript code. It seems to be a very common idiom there, particularly because JavaScript is, by its very nature, very much asynchronous and therefore dependent on callbacks. You can think of JavaScript, loosely, as based on a continuation passing style, rather than on a stack. It’s quite common to have trivial callbacks which will only ever be used in one place, although they might be added to many different selectors. In such cases, it makes sense to put these callbacks inline in the expression which assigns them, rather than elsewhere in your code.

With regards to your blog comments on anonymous methods and lambda expressions, anonymous methods could be seen as a "first step" towards lambda expressions. In a statically-type environment, lambda expressions typically have type inferencing, whereas anonymous methods, both in Delphi and C#, do not. Also, a "lambda," per se, most properly should be purely functional, although C# does not enforce this.

As for IntToStr, you’re right, it isn’t necessary. I originally wrote the code with ShowMessage, where it is required, and later changed it to WriteLn when I realized that I should show the "output."

By: Lars Fosdal

Lars Fosdal — Tue, 05 Aug 2008 14:36:11 +0000

I suspect that one of the reasons for so many having problems with realizing the impact of anon.methods, is that all the examples so far have been trivial code that can be done without anon.methods.

As soon as we start using generics, the benefits are much more clear (TCollection.ForEach f.x.), but even those can be done using sub-classing and without anon.methods.

The discussion then appear to derail over in which style (inline declared anon methods, or object protected virtual methods) that is preferable.

I made some speculations on when they could be used
http://delphi.fosdal.com/2008/08/anonymous-methods-when-to-use-them.html

but we could use something more elaborate and thought through which really shows off the power of anon.methods.

P.S. Why did you add IntToStr(i) inside the WriteLn?

By: Craig Stuntz

Craig Stuntz — Tue, 05 Aug 2008 00:57:48 +0000

Bart Roozendaal has a dissenting view (maybe):

http://blogs.sevensteps.com/2008/08/i-now-get-anonymous-methods-but-i.html

I don’t agree with Bart’s post, (though it seems from later comments like he’s starting to get it) but he’s entitled to his opinion. I’m linking it here since he mentions this post.

By: El Cy

El Cy — Mon, 04 Aug 2008 20:08:08 +0000

An interesting read in this context ….

The Evolution Of LINQ And Its Impact On The Design Of C#
http://msdn.microsoft.com/en-us/magazine/cc163400.aspx

By: Craig Stuntz

Craig Stuntz — Mon, 04 Aug 2008 16:50:38 +0000

Yes, Erik, I agree.

By: Erik

Erik — Mon, 04 Aug 2008 16:34:14 +0000

I think that some of the confusion is caused by a literal interpretation of the name of this feature. The critical benefits of "Anonymous Methods" have less to do with them not being named. If you were able to assign names to them (which is similar to what you do when when you assign them to a variable named with a given identifier), their critical features would still be in place. You mainly limit the calling scope to those that have access to the declaration location or any variable that holds a reference to the anon method, and provide the features such as variable capture. I wonder if the Delphi implementation is automatically thread-safe with respect to writing to the local variables in multiple threads, etc., or if some language features would be made available to easily control access to those variables…