Function like C# properties?

Question

I've been thinking about how C# properties work and could work.

I know the purpose that C# properties were originally designed for, which is certainly useful. However instead in this question I'm comparing them more abstractly to functions and other programic elements.

Firstly, I wondered, if it were possible, and if so why not, to have a function like C# property.

For example:

byte n = 4;

byte test // property
{
    get
    {
        return n;
    }
    set
    {
        n = value;
    }
    func
    {
        n++;
    }
}

To use as follows:

// n is 4
byte n2 = test; // get
test = 2; // set
// n is now 2
test; // function
// n is now 3

The 'n++' in this example being used only as a simple demonstration.

I also noticed that there is room for more polymorphism than just in function parameter types. For example having overload resolution by return type, get/set and private/public as well.

public test
{
    get
    {
    }
    get byte
    {
    }
    private get byte
    {
    }
    get bool
    {
    }
    get myType
    {
    }
    set byte
    {
    }
    set myType
    {
    }
    func
    {
    }
    func(bool)
    {
    }
    func(byte, myType)
    {
    }
    // etc...
}

The above example defines "test" along with reasonably fine detail involving different implementations for using test in various different ways.

More examples:

Read only:

byte test
{
    get
    {
    }
}

Function like:

test
{
    func
    {
    }
}

Function like with parameter polymorphism, returns a byte:

byte test
{
    func(bool)
    {
    }
    func(myType, Int16)
    {
    }
}

Behaves differntly depending on the type assigned to it:

test
{
    set bool
    {
    }
    set myType
    {
    }
}

Function like and could return a value or not, depending on the context it is used:

test
{
    byte get
    {
    }
    func(bool)
    {
    }
    func(byte, byte, myType)
    {
    }
}

The additional possibility for expression and code tidiness should be apparent. However I have been challenged to find specific uses.

One example of how this could be used is equality. Where a bool is expected, for example in an 'if' statement, the behaviour could be defined as being '==', however where there was either nothing to return to, or the return to was other than bool, the behaviour would instead be '='.

if (n.equals(4)) // if n == 4
    n.equals(2); // n = 2

Another example is as follows:

class my_list<T>
{
    List<T> store;
    public count
    {
        get
        {
            // unless otherwise apparent,
            // use the Int32 version.
            return (Int32)count;
        }

        get byte
        {
            byte n = 0;
            ForEach(var e in store)
                n++;
            return n;
        }

        get Int32
        {
            Int32 n = 0;
            ForEach(var e in store)
                n++;
            return n;
        }

        private get
        {
            // An implmentation of "count get" that only
            // occurs when count is used from inside the
            // my_list class.
        }

        func
        {
            print store.Count();
        }

        set int
        {
            if (value == 0)
                list.Clear();
        }
    }
}

Answer 1

I've tried to model what you are looking for using what's already available in the language. It kind of looks the same as your example:

public class Test
{
    private class SuperByteProperty : SuperProperty<byte>
    {
        public SuperByteProperty(byte v)
        {
            Get = () =>
            {
                return v;
            };
            Set = newValue =>
            {
                v = newValue;
            };
            Func = () =>
            {
                v++;
            };
        }
    }

    public void Run()
    {
        var n = new SuperByteProperty(4);
        Console.WriteLine(n.Get()); // outputs 4
        n.Set(2);
        Console.WriteLine(n.Get()); // outputs 2
        n.Func();
        Console.WriteLine(n.Get()); // outputs 3
    }
}

I'm basically creating a class holding three closures (closing over the free variable v). Here's the implementation of the SuperProperty:

public class SuperProperty<T>
{
    public Func<T> Get { get; protected set; }
    public Action<T> Set { get; protected set; }
    public Action Func { get; protected set; }
}

This is heavily inspired by Nancy btw.

Answer 2

Properties represent a well-defined concept: they represent some value that can be read and (optionally) written. I think it doesn't make much sense to expand it the way you're proposing, it just doesn't make sense conceptually to me.

I think that func “accessor” just doesn't belong there, it should be separate from the get and set accessors. And the code that uses it is confusing: just value as a statement shouldn't do anything, I certainly wouldn't expect it to do n++.

Also, what should be the meaning of your func accessor in general? “Any additional code related to the property”? I think that would be a really bad idea, you should be able to look at code and understand what it does, without inspecting the code of every method called.

All in all, I think creating a separate method with a name that clearly explains what it does is much better than your proposal.

---

As a side note, you actually can do this in IL. A property is just a grouping of several methods. And those methods are marked as Getter, Setter or Other. You could use those Other methods to do whatever you wanted, but you would need to write your own compiler for it (or modify existing one).

Answer 3

First, it isn't clear what your func is supposed to do. A property has a getter and a setter because it gets or sets the value of a clearly (if you are sensible) named property.

If your func, in this example returns current value + 1, how am I supposed to know what it does without calling it? I'd rather see a method called GetNextN()

Properties generally shouldn't mess about with the state of a property too much. That's why they are properties. If you want to mutate stuff, use a method with a clear name explaining the mutating behaviour.

What would you expect if I called any of the following:

func++;
byte v = func++;

?

So I think the reason we wouldn't see this added to the language is that it doesn't offer anything we can't already do in a much clearer fashion.

Answer 4

Why? Aren't you happy with the existent C# syntax? In order to change the syntax of a language, there must be serious reasons to do it.

Getters and setters make it easier to write code, and were a positive change through the evolution of C#. Yours, on the other hand, doesn't bring anything particularly useful. Not counting that it's hard to understand what does the piece of code in your example.

Now think about the consequences. For example, what about static analysis (and all the tools which rely on the existent syntax)?

Answer 5

You may have a point if you want to make the proposed function specific to a given property only and can't be called by other parts of code within even the same class.

Say you want to return the value of pi via a calculation and that calculation is so complex that you can't simply perform it in a set statement. The current approach is to call one or methods of the class before you could return the result. However, those methods would be exposed to the rest of the class unnecessarily and they may be called by mistake by say, a partial class developer that do not know what they are doing.

In the above scenario, introducing your concept of a function can be helpful because the function will not be called by code outside the property, hence protecting from a possible mistake. However, in no way properties should go away :)