Question

This is clearly not appears like it wouldn’t be a best practice. Can someone explain why it would not be a best practice or how this works? Any books or articles providing an explanation would be appreciated.

//The constructor public Page_Index() {      //create a local value     string currentValue = 'This is the FIRST value';      //use the local variable in a delegate that fires later     this.Load += delegate(object sender, EventArgs e) {         Response.Write(currentValue);     };      //change it again     currentValue = 'This is the MODIFIED value';  } 

The value that is output is the second value ‘Modified’. What part of the compiler magic is making this work? Is this as simple as keeping track of the value on the heap and retrieving it again later?

[Edit]: Given some of the comments, changing the original sentence some…

Answer 1

currentValue is no longer a local variable: it is a captured variable. This compiles to something like:

class Foo {   public string currentValue; // yes, it is a field    public void SomeMethod(object sender, EventArgs e) {     Response.Write(currentValue);   } } ... public Page_Index() {   Foo foo = new Foo();   foo.currentValue = 'This is the FIRST value';   this.Load += foo.SomeMethod;    foo.currentValue = 'This is the MODIFIED value'; } 

Jon Skeet has a really good write up of this in C# in Depth, and a separate (not as detailed) discussion here.

Note that the variable currentValue is now on the heap, not the stack – this has lots of implications, not least that it can now be used by various callers.

This is different to java: in java the value of a variable is captured. In C#, the variable itself is captured.