I suggest you ...

Modify the language to allow for observable properties rather than requiring explicit INPC

Something more like:

public observable int Foo { get; set; }

Rather than having to do all the manual event raising required by INotifyPropertyChanged

980 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…)
    Pete BrownAdminPete Brown (Admin, Developer Community) shared this idea  ·   ·  Admin →

    30 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...
      • JavamanJavaman commented  · 

        And perhaps and equally easy method for DependencyProperites. Right now this syntax is well it's too much... Try to read this in one breath, and better yet try to maintain it 5 years from now.

        public static readonly DependencyProperty IsSkilledProperty =
        DependencyProperty.Register("IsSkilled", typeof(string), typeof(Prototype),
        new FrameworkPropertyMetadata("Now is the time for all good men to come to the aid of their properties",
        FrameworkPropertyMetadataOptions.None,
        new PropertyChangedCallback(OnIsSkilledChanged)));

      • Mike EshvaMike Eshva commented  · 

        >>Joel Barsotti
        It's done already. You can find a realization for instance in Caliburn Micro: http://caliburnmicro.codeplex.com/

        It gets like this:
        NotifyPropertyChanged(() => PropertyName);
        where PropertyName isn't string but reference to a property.

      • shimmyshimmy commented  · 

        @Pete, omg, that's really daring, indeed compelling, and I guess this is not hard to implement either, the problem is that in some (I'd even say most) cases you call the OnPropertyChanged method, and overriding it in many classes, so the 'observable' keyword doesn't worth the effort for it's amount of usage.

      • Joel BarsottiJoel Barsotti commented  · 

        I'm only throwing in 1 vote.

        I don't neccesairly want built in language support, but I really want some what to get rid of all the magic strings. I desperately want to get rid of the strings, it kills the ability to refactor.

      • ketxketx commented  · 

        I don't think this case warrants changing the language. This could easily be done by the IDE (using code snippets) or using attributes and AOP. The former giving more flexibility to changing the implementation if needed.

      • mike.strobelmike.strobel commented  · 

        This is clearly a language/runtime feature, not a WPF feature. If, and I stress *if* language-level support was added for observable properties, it would likely mean the standard property descriptors for CLR properties would need to support change notification, and the compiler-generated properties would need to raise these change events. I would be against a syntax that generates CLR property/event pairs or a syntax which relies on INotifyPropertyChanged, as a string identifier is unreliable.

        Personally, I hate implementing INotifyPropertyChanged, and I far prefer property-specific change events (i.e. a "NameChanged" event for a "Name" property). WPF already supports this method of change notification for those of you who share my disdain for INPC.

      • Justin ChaseJustin Chase commented  · 

        I don't think you should change C# specifically to add support for this, that seems bad. However you can easily make a base class ObservableBase that implements INotifyPropertyChanged and a protected method SetAndNotify(...) or something like that.

        However I think the best way to solve this would be to allow AOP (Aspect Oriented Programming) hooks into C# itself. If you had a system like Boo does, where users can create macros to extend the language than this would solve the problem perfectly.

        In Boo you could easily create an observable macro that would give the exact same functionality as requested by this feature without requiring an changes to the language itself. C# needs this badly. The "Compiler as a Service" will go a long way for this but only if it also adds the ability to support user macros as well.

      • Pete BrownAdminPete Brown (Admin, Developer Community) commented  · 

        Thanks for all the comments. Regardless of how it is implemented, what I get from the high number of votes here is INPC is a pain point in WPF (and Silverlight) development.

      • OlegOleg commented  · 

        It's come to my mind that to be strictly WPF feature this request should be - "WPF to support fully functional binding to native properties without INotifyPropertyChanged".

        If you think about it - we are already setting intention to bind in XAML (or SetBinding) - why we need to redeclare this intention in code as a INotifyPropertyChanged implementation? Would it be nice to framework setting all backing work on their own?

        But of course, I have no idea of how to possibly make it in current .NET.

      • Kendrick HangKendrick Hang commented  · 

        Although I agree this would be some nice syntactic sugar to reduce typing and lines of code in my daily work, I would prioritize this lower than some of the other features that have been suggested. I will gladly type the INPC code out (or use snippets/attributes as suggested above) *if* I can get some other WPF features/fixes implemented that currently do not have a workaround. The notification code is pretty trivial while some of the other bugfixes/feature requests out there are not.

      • Quetzal QuintanaQuetzal Quintana commented  · 

        In my experience, this comes up most often when trying to bind UI stuff to viewmodel properties. Flash/Flex accomplishes this (specifically binding to properties), with a simple [Bindable] attribute that you add to whatever field/property you want to bind to. If Flash can do it that simply, it should be possible to do the same for WPF? Don't know if it would require some compile-time magic. Doesn't seem like something that needs to be added to C# itself, but a [Bindable] attribute somewhere in the WPF framework would be welcome.

      • Mark RendleMark Rendle commented  · 

        This is not really a WPF-specific feature request, is it?

      • Robert O'DonnellRobert O'Donnell commented  · 

        I agree that this is something that should be looked into, however I dont think extending the language is probably the right answer. The way I solve this problem for myself is I mark all properties in my view model that I want observable as virtual with empty get / set and use a dynamic proxy to generate the bolierplate code... This solution works in most situations...

      • Daniel VaughanDaniel Vaughan commented  · 

        I think it’s easy to say, ‘oh let’s throw in a keyword’ and let the compiler figure it out, but it may not be that simple.
        There are some important caveats to implementing this, which must be taken into account. My belief is that it is mostly viable for auto properties, and not for properties in general. Why?
        Well, should the INotifyPropertyChanged event be raised when the backing field changes or merely when the setter is called? If the answer is the former, and I believe it is, and there is code in the setter, how can any generated code know that the field has actually changed (without placing some serious rules around what can be done with an ‘observable’ property, or by explicitly identifying the backing field).

        If this is to be integrated into the CLR, why not INotifyPropertyChanging at the same time? Does it risk adding language bloat? Don’t get me wrong, I like the idea of doing away with the boiler plate code, yet it’s viability should be properly ascertained.

        The nameof() candidate seems like an good addition. Yet, how do we deal with explicit interface implementations, does nameof(MyExplicitProperty) return MyInterface.MyExplicitProperty, or is it made to be binding friendly and nameof(MyExplicitProperty) results in just ‘MyExplicitProperty’. The former seems the best, but there you see, we create a dependency on the implementation. The plot thickens... But, I still like the nameof() capability. Perhaps this should be moved to a separate voting item, because it would be useful in many other areas other than INPC.

        Anyway, the approach I use at the moment allows me trigger the property changed and property changing events iff the backing field change value is assigned a different value.

        public int Int1
        {
        get
        {
        return int1;
        }
        set
        {
        Notifier.Assign(Meta.Int1, ref int1, value);
        }
        }

        http://danielvaughan.orpius.com/post/Property-Change-Notification-using-a-Weak-Referencing-Strategy.aspx
        http://www.codeproject.com/KB/codegen/T4Metadata.aspx

        Cheers,
        Daniel

      • Andrej TozonAndrej Tozon commented  · 

        I don't mind writing INPC properties for each property in my VM, even if that makes my code a bit harder to read. But then again, I didn't mind writing "standard" properties too, yet there came auto-properties and cleaned up the "mess". I think this suggestion should be read as a more general suggestion to find an optimal way to implement observable properties so they wouldn't require writing so much repeated boilerplate code. A concrete/specific solution is up to discussion...

      ← Previous 1

      Feedback and Knowledge Base