Proposal/Discussion: Syntactic sugar for INotifyPropertyChanged/Changing

[the-black-wolf]

Currently the classes participating in WPF/UWP look really cumbersome:

    public class AuthenticationData: INotifyPropertyChanged, INotifyPropertyChanging 
    {
        private string _username;
        public string Username
        {
            get => _username;
            set => SetProperty(ref _username, value, onChangedAction: () => { /* my code */ });
        }

        private string _password;
        public string Password
        {
            get => _password;
            set => SetProperty(ref _password, value, onChangedActionValue: newValue => { /* my code */ });
        }

        // SECTION1
        public event PropertyChangedEventHandler PropertyChanged;
        public event PropertyChangingEventHandler PropertyChanging;

        protected void SetProperty<T>(ref T backingStore, T value,
            [CallerMemberName]string propertyName = "",
            Action onChangedAction = null,
            Action<T> onChangedActionValue = null)
        {
            if (EqualityComparer<T>.Default.Equals(backingStore, value)) return;

            OnPropertyChanging(propertyName);
            backingStore = value;
            onChangedAction?.Invoke();
            onChangedActionValue?.Invoke(value);
            OnPropertyChanged(propertyName);
            return true;
        }

        protected void OnPropertyChanging([CallerMemberName] string propertyName = "")
        {
            PropertyChanging?.Invoke(this, new PropertyChangingEventArgs(propertyName));
        }

        protected void OnPropertyChanged([CallerMemberName] string propertyName = "")
        {
            PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propertyName));
        }
       // end SECTION1
    }

instead I propose several additions which would help WPF/UWP code be cleaner and easier to make:

1. Add "notify" to class declaration:
   public notify class AuthenticationData
   This will automatically implement INotifyPropertyChanged and INotifyPropertyChanging interfaces and inline SECTION 1 code into class , setting the stage.

2. add optional notify to set accessor for auto-property:
   public string Username { get; notify set; }
   This will cause the compiler to use SetProperty to change the backstore value. If not specified, the property behaves like a regular c# property as it does now.

3. add optional Action and Action<T> delegate support into default notify set accessor
   public string Username { get; notify set(() => { /* my code */}); }

All this together will shrink the above class to this:

    public notify class AuthenticationData
    {
        public int ID { get; notify set; }
        public string Username { get; notify set(() => { /* my code */ }); }
        public string Password { get; notify set(newValue => { /* my code */ }); }
    }

Alternatively add all this through compiler attribute support, but then we'll lose the ability for local Action handling and it will also be more ambiguous :

    [Notify]
    public notify class AuthenticationData
    {
        [NotifyProperty]
        public string Username { get; set; }
        [NotifyProperty]
        public string Password { get; set; }
    }

[MkazemAkhgary]

notify keyword (while it may sound nice) but its very domain specific, I don't think it would be added. one might want keyword for dependency properties, other wants another keyword for dealing with network stuff. there you have pile of keywords that only make sense in distinct areas which is not a good thing.

Remember that c# is a general-purpose programming language

---

use of attribute seems good enough, and is already achieved unofficially

https://stackoverflow.com/a/18002490/4767498

yet another solution

https://stackoverflow.com/a/1315641/4767498

[MkazemAkhgary]

So my vote is 👍 for attribute usage. but part of your proposal seems to be using notify keyword which I'm really against it, so I have to 👎

[the-black-wolf]

Yea, it is domain specific, but it doesn't really clash with anything and the domain is pretty huge (unless you are exclusively web dev, but then most of the .net is domain specific hence .net core). In essence it's not that much different than syntactic sugar with auto-properties or expression-bodied members, or even linq, they also generate hidden code, this is just a larger chunk which leans on an interface that .net extensively uses in all rich client solutions. Not all apps are web, you can't fully escape the domain use, at least the solution I propose does not require changes to IL, its just syntactic sugar. I know some people are against syntactic sugar in general, but that sort of thinking is why Java is now dying and people are running away to Kotlin.

As for fody, I generally dislike weaving as a concept, especially on IL level, that stuff tends to pile up and then cause undebuggable issues because generated code behaves differently from the code that was typed making debugging pointless. Since .net officially uses INotifyPropertyChange for notifications, there should be a compiler level support for it in its main language (the alternative would be to dispense with interface and build it into Object or directly into IL and then rebuild all relevant portions of BCL). This should also apply for dependency and attached properties, but they are a much bigger fish to fry.

[MgSam]

The code generation proposal solves INotifyPropertyChanged (and many other scenarios). Hopefully it happens someday.

[quinmars]

I feel your pain. Using the INotifyPropertyChanged interface could take less effort. But I don't think the implementation should be baked into the language, rather the language should help you to use, implement and refactor INottifyPropertyChanged classes. To your points:

1. This can easily be done by a common base class. Most if not all MVVM libraries offer such a base class. Futhermore you are not restricted to the INotifyPropertyChanged interface, but you could for example also implement the INotifyPropertyChanging interface.

2. I prefer here the field keyword from Proposal: field keyword in properties #140:
   It reduce the lines to be written to:

public List<string> Employees
{
     get;
     set => SetProperty(ref field, value);
}

The last 4 lines are always the same you can copy and paste them or use a snippet for them. Plus if you want to change the property name or the property type, for example to IEnumerable<string>, you only have to do it at one place.

3. Without the compiler implementing the INotifyPropertyChanged interface, it is up to you how you implement it. But I strongly advice against performing additional logic in the setter body. I once did this and it ended up in spaghetti code. It's much cleaner to subscribe to the PropertyChanged event and perform the logic there.

[sandersaares]

UWP/WPF are extremely dependent on good change notification for data binding. For such a major use case, I would be very comfortable with a builtin language feature for this purpose.

[the-black-wolf]

@quinmars, you are right about comment 1, I extended the example with INotifyPropertyChanging, it is also an important aspect for audit/change tracking.