Tech Off Thread

6 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

Philosophical INotifyPropertyChanged question

Back to Forum: Tech Off
  • User profile image
    wkempf

    Imagine you have an object that implements INotifyPropertyChanged.  One of the properties, say Foo, can be modified which will in turn modify another property, say Bar.  In what order should the property change events fire (Foo followed by Bar or Bar followed by Foo), and why?

    Somewhat related, let's imagine we're writing a ViewModel for our WPF application.  We have a Widgets property and a SelectedWidget property.  If we reassign the Widgets property, the WPF databinding will indirectly cause our SelectedWidget property to be set to null.  Should be rely on this fact, or explicitly set the SelectedWidget to null in our Widget setter (which might (will?) cause a harmless redundant call)?

  • User profile image
    littleguru

    It should fire in the way the properties get changed. If A changes B the event for A should get fired before B. The appropriate order is always important in my opinion.

  • User profile image
    wkempf

    Obviously the order should matter Wink.  But even from your description, I'm not certain that you've got the right order.  Part of changing A is changing B.  That means that B gets changed first.

    I didn't want to spoil the discussion by stating my own thoughts, but maybe I should just spill it Wink.

    I think that setters should first ensure that all invariants are maintained, which means that events should probably fire after all changes to the object's state have been made.  If that's the case, the order in which they fire is irrelevant at the source (the object), and only relevant at the target (the event listener), and it's wrong to assume any order at the target.  Despite this, I think you should probably fire the events in the order in which the changes complete, so B fires before A.

    This is a simple thing, that only in corner cases will probably be of any real concern.  But it's the sort of thing always left out of consideration that gives me heart burn. Smiley

  • User profile image
    littleguru

    You're probably right. Because if you would log that stuff and run it backwards it would bring it into the old state... First would be A rolled back and then B. If you fire B before A...

    It's an interesting question. I never thought really about that, but firing the changed event was always the last thing I did in the proprety...

  • User profile image
    bdesmet

    It's a good question indeed but I do have a few concerns with the design of the properties you're describing. If setting one property causes another property's value to be changed as well, this is pretty much to be considered as a side-effect and maybe a property isn't the best choice in that case (in more complicated situations you'll have to make sure you're not causing a cycle in the chain of setter calls). For more info, check the Framework Design Guidelines on Choosing Between Properties and Methods.

    Nevertheless, there's no silver bullet to this kind of problems - the one thing that's key is to be consistent. Concerning your WPF sample, I'd rely on the SelectedWidget property to become null automatically.

  • User profile image
    wkempf

    bdesmet wrote:
    It's a good question indeed but I do have a few concerns with the design of the properties you're describing. If setting one property causes another property's value to be changed as well, this is pretty much to be considered as a side-effect and maybe a property isn't the best choice in that case (in more complicated situations you'll have to make sure you're not causing a cycle in the chain of setter calls). For more info, check the Framework Design Guidelines on Choosing Between Properties and Methods.

    Nevertheless, there's no silver bullet to this kind of problems - the one thing that's key is to be consistent. Concerning your WPF sample, I'd rely on the SelectedWidget property to become null automatically.


    There are a million reasons properties would behave the way I described.  Some simple examples:

    DueDate and DaysPastDue.  These are variations on the same data.  A change to one thus is a change to the other.  With little thought you can think of a lot of other examples that fall along these lines.  For example, think of a Rectangle and the correspondance between the corner coordinates and the width and height.

    When following the M-V-VM pattern, you'll typically have (for example) a Widgets collection and a SelectedWidget.  A change to the Widgets collection can effect the SelectedWidget property.  Those are just a few examples.

    I'm not denying these are side effects, I'm denying the assertion that properties shouldn't have side effects.

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.