A property or indexer may not be passed as an out or ref parameter

[serkan sendur]

why cant i pass property as ref parameter?

[serkan sendur]

Narue if you see this thread please help, you usually know all the logical reasons behind programming concepts.

[sknake]

Because ref uses the address of the variable. Imagine a property like this:

private bool connected;
    private string _field1;
    private string _field2;
    public string Field
    {
      get
      {
        if (connected)
          return _field1;
        else
          return _field2;
      }
      set
      {
        if (connected)
          _field1 = value;
        else
          _field2 = value;
      }
    }

Which underlying string field should "out" reference?

That should explain it all. This example is a little absurd as far as behavior but it is not uncommon for similar properties to be implemented.

[sknake]

Narue if you see this thread please help, you usually know all the logical reasons behind programming concepts.

It looks like you're asking for trouble...?

[serkan sendur]

no, i really respect her programming skills..
thanks for your answer by the way, i will examine it when i get my work done.

[sknake]

I thought of an even better example :)

public string FormText
    {
      get { return default(string); }
      set { }
    }

How do you propose the compiler would know what to do here

[serkan sendur]

but Scott then tell me how you pass a function by reference(function pointer or delegate)?

Properties are almost the same thing with class methods except for snytax differences.

That is why i mentioned Narue's name in this thread, this is just something for her.

[sknake]

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-public-properties-vs-java-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