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
Browsers and WSL  31 Mar 2024
Factory methods and functions  05 Mar 2023
Using Constructors  27 Feb 2023
An Inconvenient API  18 Feb 2023
Method Archetypes  11 Sep 2022
A bash puzzle, solved  02 Jul 2022
A bash puzzle  25 Jun 2022
Improve your troubleshooting by aggregating errors  11 Jun 2022
Improve your troubleshooting by wrapping errors  28 May 2022
Keep your promises  14 May 2022
Archives
December 2015
2015