In this case passing a function reference is more accurate for a property than the out parameter. A property is basically the same thing as a method except how you call it. A property can throw exceptions and have logic just like a method. Think of properties in the way they were implemented in java:
// Java getter & setter
private String foo;
public String getFoo() {
return this.foo;
}
public void setFoo(String foo) {
this.foo = foo;
}
// access the private variable foo like this:
bar = obj.getFoo();
versus c#
// C# public property
private String _foo;
public String Foo {
get { return _foo; }
set { _foo = value; }
}
// access the private variable _foo like this:
bar = obj.Foo;
* Code borrowed from http://cephas.net/blog/2004/02/16/c-...getx-and-setx/
Its just a pain to call getters and setters like Java implemented them (according to most developers out there, and myself) so the CLR handles it differently.
A field cannot throw exceptions and is just in memory storage of a type. You can throw an exception while trying to set a field:
(null as string).ToString() but not the field itself.
Take a look at a delegate:
public delegate void OnOpenTableEventHandler(object sender, OpenTableEventArgs e);
That is just defining a signature for a method and by using delegates you can call code outside of your assembly that you have no knowledge of at design time. A delegate is basically an 'interface' for a method -- it must implement these parameters (instead of a true interface enforcing any number of member definitions).
So think of Properties as methods and delegates as interfaces .. those two concept remain independant of field and writing with
out .
out says -- write <datatype> in to memory at 0x00000
function reference -- execute method in memory at 0x00000
I don't know how else to explain it... I hope it is a little more clear
Offline 
Marked 
