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
Modifying Words, Part the Second  16 Nov 2019
Modifying Words, Part the First  09 Nov 2019
Hashcodes  26 Oct 2019
Code Gardening  19 Oct 2019
Nullable types redux  12 Oct 2019
C# 8 and .NET Core 3.0  28 Sep 2019
Commands and CommandBinding  21 Sep 2019
Debugging word selection  14 Sep 2019
ViewModel Subscriptions  31 Aug 2019
Redux Subscriptions  25 Aug 2019
More csharp posts »
Archives
December 2015
2015