The implementation of anonymous methods in C# and its consequences (part 1)

re: The implementation of anonymous methods in C# and its consequences (part 1)

Rob Ender — Wed, 02 Aug 2006 18:12:47 GMT

This is why Java went with "anonymous inner classes can only access final parameters and local variables". No subtle side-effects here!

If C#2.0 allows you to write subtly incorrect code, why not just get rid of that damned "can't declare the same variable in nested scopes" compiler error too?

re: The implementation of anonymous methods in C# and its consequences (part 1)

Lionell Griffith — Wed, 02 Aug 2006 18:52:48 GMT

I thought the object of objects was that they could be used without knowledge of their internals. It seems here that you need to know the internals of BOTH the objects you are using and the object compiler. This is progress? Looks to me to be nothing but fire and motion to distract the competition.

I would much rather do structured and object oriented coding in C where I can know what is going on because I explcitly made it work that way. Oh wait. That's what I have been doing for almost 15 years. Never mind.

Thanks for reminding me of why I still don't want to use C++ or C#.

re: The implementation of anonymous methods in C# and its consequences (part 1)

Tyler Reddun — Wed, 02 Aug 2006 19:14:11 GMT

Allowing the lambada function to access data in the local scope of the function seems like it's the wrong answer. The lambada exists longer then the local varabile so it would be a scoping issue. Allowing it just seems to be asking for trouble.

Not that I would have even know that it did that, that is not something I would ever try myself. It just seems to be asking for trouble.

re: The implementation of anonymous methods in C# and its consequences (part 1)

HA HA HA — Wed, 02 Aug 2006 19:30:29 GMT

tylar - teh scopign isue is resolved by the rule that a varable exists as long as sombody has a refrance to it. easy. i mean 'easy' in teh abstarct.

whe're it gets weird is if youve got multipal nestad scopes invloved. say a closuare returnign a closure waht raturns a colsure. u can have moare then one closure runign around loose with reefrences to theh same object which was mabe orignaly on the stack. so if that objects a int or somthing the compilar also has to know to put on the heep an onyl put a refrence on the stack. so it can outlive the stdackframe.

wondar if u can do thatwith a registar varable? hyuk huyk hyuk!

re: The implementation of anonymous methods in C# and its consequences (part 1)

HA HA HA — Wed, 02 Aug 2006 19:33:34 GMT

linel - why do u need to know the intrenals? use it an it wroks. how meany poeople who wriate vrtual functoins or use multaple in heritance know about vtables?

re: The implementation of anonymous methods in C# and its consequences (part 1)

zahical — Wed, 02 Aug 2006 19:37:55 GMT

Funny thing, that the argument of ‘not knowing what is happening’ is being used to bash C++ or C#. I think that, for the sake of the argument, one can say that we lost track of what’s happening the moment we stopped programming in assembler or the /O2 switch appeared on the command line of the compiler. Or possibly, the moment when everyone stopped developing their own OSes – just to keep things in control.

And on the other hand – what’s not to know in the example with the anonymous delegates? I know _exactly_ what is happening – the local variable referenced in the body of the anonymous delegate and in the body of its lexically-enclosing method is one and the same, and so any changes to it are visible in both places.

MS could change the implementation someday but if the end result is the same I’d still know what’s happening.

You don’t need to know the internals of this to know what’s happening. Of course, the internals are very interesting and I think they illustrate very well Raymond’s point about the “kernel idea” and then just “doing what has to be done”.

Anyway, judging by yesterday’s and today’s comments it actually turned out that this actually is ‘not actually a .NET blog’. :-)

re: The implementation of anonymous methods in C# and its consequences (part 1)

Matt — Wed, 02 Aug 2006 19:39:01 GMT

A notable point which annoys the hell out of me but which is beautifully illustrated by your post is :

// Autogenerated by the compiler
class __AnonymousClass$0 {
MyClass this$0;
...

Anyone who's ever serialized a large object graph via binary or soap formatters will spot it pretty quick. [Serializable] is missing.
So any object graph containing one of these won't work.

Really, **really** annoying.

It is worth therefore being very aware of this distinction between 'easy' and 'hard' if you are going to use anonymous delegates and you ever use the invasive* serialization options.

My team is probably going to have a look at whether we can binary hack our dll's on loading (we already use custom assembly resolvers so it's not as big a step as it sounds) to fake in the Serializable attributes at runtime.
The ability to checkpoint almost the entire application to an arbitrary stream is *very* tempting.

Not intended as a rant - just as an additional warning to anyone looking into this functionality and its side effects.

* as opposed to the public properties / or special interface only XmlSerialization)

[I don't know what attributes the compiler autogenerates. This was an informal discussion, not a specification. -Raymond]

re: The implementation of anonymous methods in C# and its consequences (part 1)

Tom — Wed, 02 Aug 2006 20:50:44 GMT

The inner class should have access to the outer classes members and functions, regardless of protection (public, private, etc.) If you consider the outer class as a translation unit, the that class' variables and functions can be considered "global" to the inner class. The outer class should not have access to the inner class' members just as global functions do not have access to class' private members and functions (unless explicitly provided).

In Raymond's "hard" example where the delegate accesses local variables, thus causing compiler generation of anonymous classes, I don't see how this is any different from a closure. But I suppose that if there are two things that are hard for programmers to get (besides pointers and recursion -- but that's a different story) it's closrues and coroutines.

With regard to Matt's complaint about serialization, I agree that is annoying. I'd also say that it was a valid language/compiler design choice. If you have the compiler automatically make closure/anon classes serializable, it will likely impose limits on the types of the data members in said class. As a language designer, the tradoff would be making anon classes serializable but limited, or making anon classes unlimited but classes using delegates with anonymous classes unserializable.

In the end, the anon classes are just syntactic sugar anyway, so why not just make named serializable delegates?

re: The implementation of anonymous methods in C# and its consequences (part 1)

TW — Wed, 02 Aug 2006 21:40:54 GMT

I appreciate your C# insights, you have a skill at explaining things.

However, I have to agree with many people that I don't completely grasp /why/ annoymous methods are so great. On a technical level what is gained over named delegates/ methods or just manually inlining the code? I guess I view it as another tool in my toolbox that I don't understand why it exists.

re: The implementation of anonymous methods in C# and its consequences (part 1)

Azrael — Wed, 02 Aug 2006 22:17:04 GMT

Is this _actually_ how the CLR (or C#... is this language specific?) implements closures? Or only _conceptualy_? Doesn't it use a more compact representation?

I can see why having a "complete" class with the environment as member variables may be better by "playing nice" (or "playing by the book") with the CLR, so this is not a critique, only a question...

re: The implementation of anonymous methods in C# and its consequences (part 1)

Lionell Griffith — Wed, 02 Aug 2006 22:24:17 GMT

I have apparently hit a few hot buttons by saying that there are application classes that are not well solved by using .NET, C++, or C#. They are good tools for low performance and simple CRUD centric applications on or off the internet and little else. If that's what you do, expect your job to be outsourced in a few months to a year, if not next week.

Meanwhile, I will accomplish my goals my way.

re: The implementation of anonymous methods in C# and its consequences (part 1)

Anonymous — Wed, 02 Aug 2006 23:57:09 GMT

> Funny thing, that the argument of ‘not knowing what is happening’ is being used to bash C++ or C#.

I find it funnier when MSDN already has a growing collection of articles on the intricacies of C#, yet some people claim that C++ is an abomination purely because there are some subtle details.

I'm not sure if "HA HA HA"'s badly spelled rants are entirely serious - but fanboys are always funny, regardless of the object of their affection. ;)

re: The implementation of anonymous methods in C# and its consequences (part 1)

Wed, 02 Aug 2006 23:59:25 GMT

Lionell: I think you missed the point of the article, which is about anonymous functions, and nothing to do with objects really. The same idiosyncracies come up in other languages like LISP, which is functional, and has closures/lambda functions. Your little rant didn't make much sense in context.

TW: I tend to agree that anon functions bring in a lot more complexity than they're worth, at least from my experience, true closures can be pretty nasty. Having the compiler generate anonymous functions for simple wrappers can be very handy though, if for nothing else to prevent the namespace from getting cluttered with trivial functions.

re: The implementation of anonymous methods in C# and its consequences (part 1)

ccx — Thu, 03 Aug 2006 00:25:59 GMT

Gosh!
From what i use to see in other sites about programming languages, i thought people would say: "Great, finally C# has this new cool feature (closures)!". Instead, what i see is people bashing a useful feature just because they don't quite understand it. Maybe recursion and virtual funcionts received the same bad looks when they were introduced...

Am i the only one who **likes** when a programming language has more features? Or do everybody prefer minimalistic languages where you have to reimplement everything (including pass-by-reference, as in Java)?

re: The implementation of anonymous methods in C# and its consequences (part 1)

Alyosha` — Thu, 03 Aug 2006 01:06:56 GMT

I am reminded of why I still don't want to use C every time I call malloc, every time I want to concatenate two strings (or for that matter, every time I want to model a 1:n relationship without fixing the value of n to some hard-coded constant), every time I want to deep copy a struct, and every time I check the same damn error code through ten call stack frames.

It's not that we don't know how to program in C. We do. We know how bad it sucks. We know that a C program can be replaced by an equivalent C++ or C# program in half the number of lines of code or less, without sacrificing performance (re-read Raymond Chen's series on building a Chinese / English dictionary). We know that complexity scales exponetially with LOC; that's why we want the compiler to generate all that boilerplate, instead of fetishizing our ignorance and insisting on using an exacto knife for a job that requires a chainsaw.

Lionell, if you can't be bothered to learn something new after 15 years, perhaps you should be the one worried about your future employability.

re: The implementation of anonymous methods in C# and its consequences (part 1)

TW — Thu, 03 Aug 2006 01:13:09 GMT

ccx:

I'm not opposed to anon methods. As you said I don't understand them so I have trouble seeing the usefulness. When I first started programming I thought the same thing about function pointers (functors, delegates, whatever). I now love them.

I think part of the one sided-ness of the comments could just show who reads "The Old New Thing". Namely, C/ C++ coders, not C#.

Tools change, sometimes for the better, sometimes not. More tools are not a bad thing as long as they make the builders more productive and they enjoy using them.

re: The implementation of anonymous methods in C# and its consequences (part 1)

bok — Thu, 03 Aug 2006 01:49:13 GMT

How does this work in a function containing multiple anonymous functions sharing a subset of local variables? I'd guess there'd either have to be one anonymous class created which shares all local variables referenced by any anonymous functions, or else a tree of anonymous classes referencing others depending on scope. The first seems like it could cause some massive memory leaks you wouldn't expect, but the second would be harder for the compiler and could easily generate some horrible code for all the dereferences in edge cases.

(I'm not a C# programmer, but enjoyed the article btw...)

re: The implementation of anonymous methods in C# and its consequences (part 1)

Anonymous — Thu, 03 Aug 2006 07:47:56 GMT

> The first seems like it could cause some massive memory leaks you wouldn't expect

Two words: Garbage collection.

re: The implementation of anonymous methods in C# and its consequences (part 1)

CN — Thu, 03 Aug 2006 09:42:14 GMT

Anonymous: The point of bok is more subtle, if anon method a keeps a reference to a local variable that's a huge dictionary z, and anon method b is a simple "return x + y" method, and b is shared by both anon functions, then the reference to z would be kept as long as there was any reference to anon method b. Not so good, or at least a real issue. It could be one of the cases where some knowledge of the actual implementation is needed.

An interesting read on anonymous methods.

Wouter van Vugt — Thu, 03 Aug 2006 10:17:53 GMT

re: The implementation of anonymous methods in C# and its consequences (part 1)

Matt — Thu, 03 Aug 2006 12:35:04 GMT

[I don't know what attributes the compiler auto generates. This was an informal discussion, not a specification. -Raymond]

Sorry I wasn't trying to pick at anything in your example - your example was completely correct in not having the attribute.
I was just pointing out the limitations imposed by the silent hoops the compiler jumped through in the hard case.

I agree simply adding it willy nilly would also be unrealistic since it would needlessly constrain things in another (far more important) direction.

For the record I love anon delegates for two principle reasons neither of which rely on the 'hard' case.
As already mentioned by others they reduce the need for a separate function name (which as an event handler callback is probably not something you should be calling directly).

But better still for a very small function (hopefully one or two lines) they provide greater 'cohesion' between the event subscription and the desired behaviour when it executes. I love this and find, when used well, it dramatically improves the readability of the code. I find reading the auto generated names from the designer a little ugly (but baring anon delegates have no better solution to offer :)

re: The implementation of anonymous methods in C# and its consequences (part 1)

Paul — Thu, 03 Aug 2006 13:06:21 GMT

TW:

One great use for anonymous delegates is unit testing event handlers; each test can be self contained and not require any additional methods to handle the event.

re: The implementation of anonymous methods in C# and its consequences (part 1)

Azrael — Thu, 03 Aug 2006 14:47:32 GMT

CN: I don't really understand... Assuming that's something like this:

BigDictionary z;
anon_a = delegate (x) { return z[x]; }
anon_b = delegate (x,y) { return x + y; }

And assuming that both anon_a and anon_b are returned, the compiler will generate one wrapper class and use for anon_a, but anon_b falls into what Raymond classified as the easy case.

Unless anon_b directly references either z or anon_a, it is unrelated to z, therefore has no impact on the lifetime of z.

It is easier if you think that each closure (delegate...) has an internal hashtable with the variables that it refers and are not parameters. This hashtable maps the name of the variable to a reference to it. The wrapper class thingy is only an implementation detail of C#/CLR.

re: The implementation of anonymous methods in C# and its consequences (part 1)

bok — Thu, 03 Aug 2006 17:27:27 GMT

Azrael: I don't believe that was what CN meant. My original point was more the following situtation:

int w;
BigDictionary z;
anon_a = delegate (x) { return z[x + w++]; }
anon_b = delegate (x) { return x + w++; }
if( something )
{
return anon_a;
}
else
{
return anon_b;
}

Neither anonymous function fits into the easy case, because both reference 'w'. If anon_b happens to be returned, does the anonymous class include a live reference to 'z' as well? There can't be different anonymous classes which both contain 'w', in case either delegate modifies it.

re: The implementation of anonymous methods in C# and its consequences (part 1)

Patrick Smacchia — Thu, 03 Aug 2006 20:22:03 GMT

Here you can read some articles extracted from my book 'Practical .NET2 and C#2' where I explain the 'under the hood' of iterators in C#2 and how they are related to anonymous mehods:

http://www.theserverside.net/tt/articles/showarticle.tss?id=AnonymousMethods

http://www.theserverside.net/tt/articles/showarticle.tss?id=IteratorsWithC2

re: The implementation of anonymous methods in C# and its consequences (part 1)

Scott Tringali — Fri, 04 Aug 2006 05:21:23 GMT

Allowing the lambada function to access data in the local scope of the function seems like it's the wrong answer.

Is that the forbidden dance function? (http://en.wikipedia.org/wiki/Lambada)

Interesting Finds: August 2

Jason Haley — Fri, 04 Aug 2006 06:25:57 GMT

weekly linkdump « ???????? ?????????????????????????? « developers.org.ua

weekly linkdump « ???????? ?????????????????????????? « developers.org.ua — Fri, 04 Aug 2006 08:02:54 GMT

PingBack from http://www.developers.org.ua/archives/max/2006/08/04/weekly-linkdump-39/

Implementacja metod anonimowych w C# 2.0

my friend - visual — Sat, 05 Aug 2006 22:59:34 GMT

Na blogu oldnewthing pojawił się&nbsp;trzy częściowy&nbsp;artykuł o implementacji metod anonimowych w...

re: The implementation of anonymous methods in C# and its consequences (part 1)

Neil — Tue, 08 Aug 2006 01:29:27 GMT

CN/Azrael/bok, the page Raymond linked to in a later entry seems to suggest that the comparative lifetime depends on the scope the variable is declared in. This means that you could declare z in an inner scope to w so that anon_b wouldn't need to keep a reference to z.

The implementation of anonymous methods in C# and its consequences

Eric Gunnerson's C# Compendium — Tue, 08 Aug 2006 20:23:44 GMT

Raymond wrote a really nice series of posts on this:

Part 1
Part 2
Part 3
He also points out that...

re: The implementation of anonymous methods in C# and its consequences (part 1)

Bill Cohagan — Tue, 08 Aug 2006 20:43:14 GMT

This is an interesting thread -- one that reminds me strongly of discussions threads I was involved in back in the '70s when we (a group of developers) were trying to get a grasp of closures and continuations in Scheme. I would strongly recommend that people interested in learning more about these take a look at Guy Steele's "The Lambda Papers" (http://library.readscheme.org/page1.html) An excellent introduction to the power of these ideas is Dan Friedman's "Little Schemer" book.

These are certainly not concepts that are either new or Microsoft specific. They certainly are very powerful concepts and I for one am tickled pink that they are showing up in languages such as c#.

If you don't take the time and effort to understand them they will remain "quirky" facets of the language. If you *do* take the time then I believe your code will be the better for it.

Regards,
Bill

The implementation of anonymous methods in C# and its consequences #1

DotNetKicks.com — Wed, 09 Aug 2006 10:51:14 GMT

You've been kicked (a good thing) - Trackback from DotNetKicks.com

Anonymous Methods -> code bloat

Anonymous Methods -> code bloat — Mon, 14 Aug 2006 18:09:19 GMT

PingBack from http://blogs.dotninjas.dk/t4rzsan/archive/2006/08/14/1531.aspx

An interesting read on anonymous methods.

Wouter van Vugt — Sun, 03 Sep 2006 22:07:38 GMT

An anonymous method is of course not anonymous at all, how else would you find it runtime if it were?

Tim Van Wassenhove » Blog Archive » Anonymous methods

Tim Van Wassenhove » Blog Archive » Anonymous methods — Sun, 17 Sep 2006 00:13:14 GMT

PingBack from http://timvw.madoka.be/?p=622

Tim Van Wassenhove » Anonymous methods

Tim Van Wassenhove » Anonymous methods — Sun, 08 Oct 2006 03:03:10 GMT

PingBack from http://www.timvw.be/anonymous-methods/

О сокрытии

Items — Wed, 25 Oct 2006 12:31:25 GMT

Вместо эпиграфа: information hiding (1) In programming, the process of hiding details of an object or

FYI: C# and VB Closures are per-scope

Fabulous Adventures In Coding — Thu, 07 Jun 2007 21:13:02 GMT

This post assumes that you understand how closures are implemented in C#. They're implemented in essentially

Implementation of anonymous methods in C#

I hate Spaghetti (code) — Mon, 25 Jun 2007 20:07:05 GMT

I read a nice and not too complicated post regarding the "behind the scenes" of anonymous methods. I

Anonymous Delegates or DisposableActions?

Doron's .NET Space — Thu, 09 Aug 2007 22:41:13 GMT

One of the most useful features of .NET 2.0 is anonymous delegates. They allow you to create "wrappers"

Julio C??sar Carrascal Urquijo » Archivo » D should have real closures.

Julio C??sar Carrascal Urquijo » Archivo » D should have real closures. — Thu, 13 Sep 2007 08:01:27 GMT

PingBack from http://jcesar.totumo.net/2007/09/13/d-should-have-real-closures/

New for Visual Studio 2008 - Support for anonymous methods and lambda expressions

The Visual Studio Code Analysis Team Blog — Fri, 21 Sep 2007 18:36:08 GMT

One of my favorite new features for Code Analysis in Visual Studio 2008 is our support for analyzing

.Net Learning Curve » Blog Archive » C# nested classes (vs Java)

.Net Learning Curve » Blog Archive » C# nested classes (vs Java) — Sat, 17 Nov 2007 18:44:21 GMT

PingBack from http://dotnet.robertmao.com/2007/11/17/c-nested-classes-vs-java/

String-less ArgumentNullException

Doron's .NET Space — Sun, 09 Dec 2007 21:58:01 GMT

The post I wrote yesterday about Expression Trees has inspired to find some more cool usages for this

Paul Stovell says… » Tip: “Almost-anonymous” methods in Visual Basic .NET

Thu, 05 Jun 2008 17:45:23 GMT

PingBack from http://www.paulstovell.com/blog/almost-anonymous-methods-in-visual-basic-net

ReSharper: Access to modified closure

Patrick Steele's .NET Blog — Mon, 06 Apr 2009 22:20:49 GMT

On the advice of Jay Wren , I decided to try our ReSharper 4.1 .  I had previously installed DevExpress

ReSharper: Access to modified closure

Patrick Steele — Mon, 06 Apr 2009 22:26:57 GMT

On the advice of Jay Wren , I decided to try our ReSharper 4.1 .  I had previously installed DevExpress'

For once and for all: Delegates, Events, Anonymous Methods and Lambda Expressions « Hungry for Knowledge

Thu, 21 May 2009 21:53:23 GMT

PingBack from http://sdesmedt.wordpress.com/2009/05/21/for-once-and-for-all-delegates-events-anonymous-methods-and-lambda-expressions/

Anonymous Methods Internals | Beyond The Spec

Anonymous Methods Internals | Beyond The Spec — Fri, 19 Jun 2009 02:52:15 GMT

PingBack from http://beyondthespec.com/blog/2009/06/19/anonymous-methods-internals/