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
Simple Queues  17 Nov 2018
Enqueuing Values  10 Nov 2018
Dequeuing Values  03 Nov 2018
Designing the External API  27 Oct 2018
Introducing the Priority Queue  20 Oct 2018
A better approach to reflection  13 Oct 2018
Avoiding Magic Strings  06 Oct 2018
Capturing Validation Metadata  29 Sep 2018
Modelling Validation Metadata  22 Sep 2018
Validation Metadata  15 Sep 2018
More csharp posts »
Archives
December 2015
2015