A Proposal for an Enhanced C# Property syntax

Introduction

Microsoft .NET platform has provided software programmers with a set of very powerful languages like VB, C# etc. and growing. The syntax for writing code in these languages is somewhat very similar since they all use the Microsoft CLR (Common Language Runtime) which forms the core of the .NET platform.

Most modern Object Oriented (OO) languages provide support for Primitive Types, Classes, Methods, Operators, Exception Handling, Threading, Event Handling and Program Flow Control. While working with C#, I thought that some features of the language could have been implemented a little differently to provide more flexibility.

This article, the first amongst a series of articles will suggest enhancements in some of the feature areas mentioned above for the .NET languages. The examples in this article are written using C# language syntax assuming that the reader is familiar with the same.

What are CLR Properties?

The CLR uses a new syntax for defining properties of a class. A CLR property is a member of type that specifies one or two methods that correspond to the named value. This syntax makes the property look as if it were a field on that class (Also referred to as Smart Field). The syntax is a hybrid of field and method syntax or property is a cross between a logical field and physical method.

The structure of a CLR Property is as shown in the figure above. A property consists of a maximum of two accessor methods (get/set) and it's associated Type. The PropertyInfo class provides access to property metadata and discovers the attributes of a property. It provides access to it's underlying methods via calls to the GetAccessors() (returns MethodInfo objects for both the set and get methods), GetGetMethod() (returns the MethodInfo object for the get method) or GetSetMethod() (returns the MethodInfo object for the set method) methods. The PropertyType property (no pun intended) returns the type of the property.

// Current Permissible C# Property Syntax
public class Foo
{
  private string name;
  public string Name
  {
    get { return this.name; }
    set { this.name = value; }
  }
}

The above property syntax results in the generation of two methods which are marked with a specialname metadata attribute, which informs the compilers and tools (e.g. IntelliSense) to hide the properties individual methods from normal use. In case you are wondering, this is precisely why properties cannot be passed to methods using the ref or out keywords which is possible if you used fields instead.

public string get_Name() // The getter.
public void set_Name(string value) // The setter.

Analyzing the Problem

Quite often we need a different access scope for the property getter and setter for better encapsulation. Typically, the public scope is assigned to the getter where as the lesser protected scope could be applied to the setter. This makes the setter only visible to the sub-classes and prevents any external module or application from changing the state of our object using the otherwise public property setter.

Problem: The current CLS (Common Language Specification) only allows us to have one access qualifier for every property declared within a class. Assigning different access modifiers to the getter and setter of a property will result in a compilation error. Consider the modified code for a class Foo listed below:

public class Foo
{
  private string name;
  public string Name
  {
    get { return this.name; }
  }
  // Compiler Error! The class 'Foo' already contains a definition for 'Name'.
  protected string Name
  {
    set { this.name = value; }
  }
}

Workaround: Define a public read-only property in addition to a protected method(!) which sets the value on the property as shown below. This negates the premise of making a property look like a smart field.

private string name;

// Current C# property syntax. Public getter for name.
public string Name
{
  get { return this.name; }
}

// Protected SetName method definition.
protected void SetName(string name)
{
  this.name = name;
}

// Somewhere else in the code, access the property of object type foo
Foo foo = new Foo();
string name = foo.Name; // Ok

foo.SetName("myName"); // Not intuitive anymore.

Proposal: The proposed syntax for defining a property is as shown below. Only one getter and setter irrespective of the access scope should be permissible. This new syntax also enables programmers to use the virtual keyword individually for either the getter/setter or both.

// The desired syntax Public getter and protected setter. 
virtual public string Name
{
  get { return this.name; }
}

// Protected setter access. Should compile Ok as only one setter is defined
protected string Name
{
  set { this.name = value; }
}

The above property syntax would result in the generation of two methods as before but with the appropriate modifications to the access and virtual qualifiers.

virtual public string get_Name() 
// The getter.  Notice the virtual keyword and public access modifier.
protected void set_Name(string value) 
// The setter. Notice the protected access modifier.

The following code with the new proposed syntax should result in a compiler error as only one getter and setter is permitted per property.

public string Name
{
  get { return this.name; }
  set { this.name = value; }
}
// Error Duplicate definition of the Name setter
protected string Name
{
  set { this.name = value; }
}

// OR

public string Name
{
  get { return this.name; }
  set { this.name = value; }
}
// Error Duplicate definition of the Name setter
protected string Name
{
  get { return this.name; }
}

I hope that C# properties in the future will become more friendlier if the C# community takes notice. Til' then Happy Netting...

References/Links

Essential .NET Volume 1 (The Common Language Runtime) - Don Box with Chris Sells.

Inside C# - Tom Archer.

Microsoft Visual C# .NET Step By Step - John Sharp, Jon Jagger.

Alternative Simplified C# Property Syntax (Proposal) - Scott Zimmerman article on C# Corner.