I suggest you ...

INotifyPropertyChanged

Provide a way for INotifyPropertyChanged to be implemented for you automatically on class.

Provide a way for INPC to be done on auto properties (that you mark in some way)....so that you don't have to unroll the auto property into a field, and raise yourself.

917 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    jamsjams shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    16 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • Konstantin IsaevKonstantin Isaev commented  ·   ·  Flag as inappropriate

        Syntax can be like so:
        public class A: INotifyPropertyChanged {
        public string Property1 { get; set; notify as "Property1"; }
        public string Property2 { get; set; notify; } //property name picked automatically as "Property2"
        }

      • MartinMartin commented  ·   ·  Flag as inappropriate

        I like the idea of a NotifyPropertyChanged attribute that causes a standard "if (a != b) ..." test to be generated but offers an override that can take an optional IComparer as a parameter for the more complex test and provide custom control over that test (generating "if (comparer.Compare(a, b) != 0) ...".

        The NotifyPropertyChanged attribute would only then be allowed to be specified against automatic properties on a class that implements INotifyPropertyChanged.

      • Ramon de KleinRamon de Klein commented  ·   ·  Flag as inappropriate

        Implementing INotifyPropertyChanged properly requires some repeating programming effort for each property. It also used to be error-prone, but this can be resolved in C# 5 using the CallerMemberName attribute. It would be more convenient to use automatic properties with INotifyPropertyChanged support. The 'SupportINotifyPropertyChanged' attribute can be applied to automatic properties and this result in the following code:

        [SupportINotifyPropertyChanged]
        public string Description { get; set; }

        Is compiled to something like this:

        private string __description;
        public Description
        {
        get { return __description; }
        set {
        if (__description == value) return;
        __description = value;
        var propChanged = (INotifyPropertyChanged)this; /* prevents race condition */
        if (propChanged != null)
        propChanged(this, new PropertyChangedEventArgs("Description"));
        }
        }

        A compilation error will be emitted if the class (or one of its parents) doesn't implement the INotifyPropertyChanged interface.

        As an addition the 'SupportINotifyPropertyChanged' attribute could also take an optional Func<T,T,bool> delegate (or use IEqualityComparer<T>) that is used to check if the new value is different for more complex scenarios.

      • Ramon de KleinRamon de Klein commented  ·   ·  Flag as inappropriate

        Implementing INotifyPropertyChanged properly requires some repeating programming effort for each property. It also used to be error-prone, but this can be resolved in C# 5 using the CallerMemberName attribute. It would be more convenient to use automatic properties with INotifyPropertyChanged support. The 'SupportINotifyPropertyChanged' attribute can be applied to automatic properties and this result in the following code:

        [SupportINotifyPropertyChanged]
        public string Description { get; set; }

        Is compiled to something like this:

        private string __description;
        public Description
        {
        get { return __description; }
        set {
        if (__description == value) return;
        __description = value;
        var propChanged = (INotifyPropertyChanged)this; /* prevents race condition */
        if (propChanged != null)
        propChanged(this, new PropertyChangedEventArgs("Description"));
        }
        }

        A compilation error will be emitted if the class (or one of its parents) doesn't implement the INotifyPropertyChanged interface.

        As an addition the 'SupportINotifyPropertyChanged' attribute could also take an optional Func<T,T,bool> delegate (or use IEqualityComparer<T>) that is used to check if the new value is different for more complex scenarios.

      • BrettBrett commented  ·   ·  Flag as inappropriate

        This is improved in VS11 net4.5 to use the method name optionally as [CallerMemberName] string PropertyName where the callername is subsitituted if no explicit name is supplied

      • Miha MarkicMiha Markic commented  ·   ·  Flag as inappropriate

        Agree with Schuster-Rainer - AOP is the way to go. Roslyn might have this feature albeit I doubt it (due to the political decisions). As for now, there are AOP 3rd parties ranging from free ones (as RIchard pointed out) to much more powerful (not free, but well worthi it) PostSharp.
        The bottom line is that if MS is to add this feature it will be a part of Roslyn. And yes, I am totally in favor of such a feature.

      • aprapr commented  ·   ·  Flag as inappropriate

        This idea won't work for a winform/wpf(?) application, when the property is changed in a non-ui thread.

      • QwertieQwertie commented  ·   ·  Flag as inappropriate

        I would only support this idea as part of a far more general metaprogramming feature. I imagine writing an auto-property like [FirePropertyChanged] int Foo {get;set;}, and then a compile-time FirePropertyChangedMetaAttribute(...) method would transform that into a property that fires PropertyChanged when called.

      • Schuster-RainerSchuster-Rainer commented  ·   ·  Flag as inappropriate

        Implement serverall compiler stages, or some kind of macros / AST transformation, or simply AOP, so this will be no problem anymore.

      • Alan RotenbergAlan Rotenberg commented  ·   ·  Flag as inappropriate

        Tangential to this but very related, it's kind of annoying to always have to test if an event is null before raising it. It's pretty tedious to always have to test of PropertyChanged is null. It should just do nothing if there are no subscribers.

      • Tuomas HietanenTuomas Hietanen commented  ·   ·  Flag as inappropriate

        It would be nice to have it like attribute to class, like [NotifyPropertyChange]

        However, events are actually just side effects (hard to test etc.), so I think that the whole event-driven software development model is bad. It seems to be the default model. :-(

      • DaverDaver commented  ·   ·  Flag as inappropriate

        Most of the time, creating this INotifyPropertyChanged code is just mindless grunt work. It would be nice if it was assumed by convention to work a starndard way. And if you need it to behave non-standard, then allow it to be overridden somehow.

      • DaverDaver commented  ·   ·  Flag as inappropriate

        Most of the time, creating this INotifyPropertyChanged code is just grunt work. It would be nice if it was assumed by convention to work a starndard way. And if you need it to behave non-standard, then allow it to be overridden somehow.

      • AnonymousAnonymous commented  ·   ·  Flag as inappropriate

        Also add Raise feature like in VB and auto-event support with thread-safe raise implementation
        public event EventHandler ChangingEvent { add; remove; raise; }

      Feedback and Knowledge Base