How are properties included when calling\invoking a method

15y978Azure

Hi,

Say if I have the following code snippet:-

Class Class1
{
   public string fullName { get; set; }
   public string FullName { get; set; }

   public string ToString()
        {
           fullname = this.FullName;

            if (fullname == null)
           {
                   return base.ToString();
                }

           return fullname;
        }
}

When the ToString method is called, is it the default constructor that includes and initializes the 2 properties, as obviously these fall out of scope\range of the method implementation?

I know that fields are included in the default constructor, but does this apply to properties also?

Regards,

3 Replies

Know the answer? Post it — somebody with the same question will find it here.

Vulpes15y ago
Accepted answer
When you use an 'automatic property', like the two in Class1, then the compiler generates a hidden field. This is initialized to its default value (null for all reference types including string) when the object is created unless it's set to some other value in the constructor.

So here the hidden fields are null initially and the properties therefore return nulll as well.

There's no way to access this hidden field from C# which is given a compiler-generated name.
Vulpes15y ago
As Sam says, properties are essentially methods and usually (though not always) they provide guarded access to a private field.

For example, before C# 3.0, code such as the following was (and, indeed, still is) commonplace:

   private string fullName; // private 'backing' field

   public string FullName
   {
   get { return fullName; }
   set { fullName = value; }
   }

The compiler turns the property into two methods:

   public string get_FullName() { return fullName; }
   public void set_FullName(string value) { fullName = value; }

and you could in fact do something like this 'manually' if you wanted to. In fact in languages such as C++ and Java which don't support properties you have to write 'get' and 'set' methods manually.

However, in practice, property notation is more convenient and allows you (for most purposes) to treat the property as a 'smart' field. For example, if you need to ensure that fullName is never assigned an empty string, you can put a line in the 'setter' to prevent this.

Even in the situation where the property does no more than get or set the value of a private field, it is usually recommended that you should still use a property rather than simply make the field public. This is because, if you decide to change it later, the interface of the class would change because data and methods are different things.

Consequently, the above pattern for writing properties was extremely common before C# 3.0 and Microsoft therefore came up with 'automatic properties' so developers wouldn't have to go through this rigmarole every time.

Now, when the compiler sees this:

  public string FullName { get; set; }

it turns it into this:

  private string k__BackingField = null;

  public string get_FullName() { return k__BackingField; }
  public void set_FullName(string value) { k__BackingField = value; }

The private backing field is completely inaccessible from ordinary C# code because it doesn't even satisfy the rules for C# identifiers which can only begin with a letter, digit or underscore (this restriction doesn't apply to CIL). However, you can use reflection to show that this is so by running this little program:

  using System;
  using System.Reflection;

  class Test
  {
   public string FullName { get; set; }

   static void Main()
   {
   BindingFlags bf = BindingFlags.Instance | BindingFlags.NonPublic;
   Type t = typeof(Test);
   FieldInfo[] fia = t.GetFields(bf);
   foreach(FieldInfo fi in fia) Console.WriteLine(fi.Name);
   Console.ReadKey();
   }
  }

So, automatic properties are just a shortcut for writing properties where you don't need to access the backing field directly. Although both 'get' and 'set' need to be present, you can make the latter private if you want the property to be read-only from external code. The backing field will have it's default value for the type in question, unless you set the property to something else from the constructor.
Sam Hobbs15y ago
Obviously Vulpes understand the C# language more than I do. I think it will help to clarify somne things though.

I think a property should be considered a method, certainly to the extent that a constructor is not relevant in this context. The sample code that you show happens to work a little differently, and I would not be able to explain things as accurately as Vulpes has. I think however that the sample code might cause confusion since it is not normal for memory to be allocated for data corresponding to a property.