What if a property declaration was a scope, inside which you could declare additional members - more than just the standard get and set declarations?

As .NET developers, we’re all familiar with the standard C# property declaration and the associated member variable:

public string Name 
{
    get { return mName; }
    set { mName = value; }
}

private string mName;

Over on the Born to Code blog, Roland Weigelt brings up an interesting idea for enhancing C# - treating the property declaration as a scope, in which a variable declaration could be made.

Such a feature would allow you to encapsulate the relevant member variable, preventing access except via the properly accessors. It might look like this:

public string Name 
{
    get { return mName; }
    set { mName = value; }

    private string mName;
}

The obvious advantage is in the way it keeps all the related declarations together.

Let’s try a thought experiment and see what happens if we take this idea further.

By treating the property declaration as an arbitrary scope and allowing other declarations, we could create a property that knows if it has been modified:

public string Name
{
    get { return mName; }
    set { mName = value; }

    public bool Modified
    {
        get { return !Equal(mName, mOriginal);
    }

    public void Load(string value)
    {
        mName = value;
        mOriginal = value;
    }

    private string mName;
    private string mOriginal;
}

Here’s a demo showing how this might be used:

myPerson.Name.Load("Teddy Bear");     // Set the original value
var changed = myPerson.Name.Modified; // Returns false
myPerson.Name = "Ted E. Bear";        // Modify the value
changed = myPerson.Name.Modified;     // Returns true

What should happen if the name of a subproperty or submethod conflicts with a member that already exists on the property type? One approach would be to make it a compilation error, but perhaps a strategy in line with extension methods where existing members take priority would be good ideas, not least because of its consistency. Another potential solution would be to use a different operator (perhaps ‘..’) to keep things in different scopes.

A big disadvantage of this syntax is that it lacks reusability - code written to provide this functionality for one property can’t be reused for another. This is probably in itself sufficient reason that this would never see the light of day - but it’s an interesting experiment none the less.

Comments

blog comments powered by Disqus
Next Post
SharpDox Tips  02 Jan 2016
Prior Post
Consideration Driven Development  13 Dec 2015
Related Posts
Equality has Symmetry  17 Mar 2018
Type Miscellany  05 Mar 2017
Testing Immutable Types  25 Feb 2017
Factory Methods  18 Feb 2017
Queue Concatenation  11 Feb 2017
Complex Queues  04 Feb 2017
The Problem with the Simple Queue  28 Jan 2017
Enumeration of Queues  21 Jan 2017
Reversing Stacks  14 Jan 2017
Simple Queues  07 Jan 2017
More csharp posts »
Archives
December 2015
2015