Why does RaiseAndSetIfChanged return TRet instead of bool?

[chrbkr]

RaiseAndSetIfChanged returns newValue, and the documentation even states that this is normally discarded. But what's the reasoning behind this redundant return value? Why not return bool like other MVVM frameworks, so in the setter you can do stuff depending on whether or not the property has actually been changed?

[glennawatson]

Usually you are encouraged in the reactive world to monitor the property with an observable and build up your on set actions from there.

You can use ObservableAsPropertyHelper etc

[chrbkr]

Thanks for the quick response. For external use, this makes perfect sense, but for the use inside the class itself, it sounds like unnecessary overhead to me. But I just stumbled across ReactiveUI, and I need to learn a lot, so I might be completely wrong.

[glennawatson]

It depends on what you are doing if its unnecessary overhead. If you are having data that comes from a lot of different threads, or processing a lot of data coming from a external database, even internally inside the class it makes sense to use Rx based concepts. E.g. you can route back onto the appropriate threads with a Linq like statement very quickly/easily.

So conceptually makes things much more performant since you are removing code that relies on state from your internal class.

If you're building a smaller application that doesn't rely on all this then maybe.

In terms of our API we probably wouldn't change the value to return a boolean, since this would be a breaking change on our users. Since it is a extension method nothing stopping you from making your own that does though.

[chrbkr]

I see. Do you have an example where returning the new value might be useful?

[glennawatson]

Languages such as F# which don't have native concepts such as properties per say use it in for their functional form.

[glennawatson]

You can also potentially chain the RaiseAndIfChanged into your observable pipeline and return the value into the observable chain.

[anaisbetts]

Why not return bool like other MVVM frameworks, so in the setter you can do stuff depending on whether or not the property has actually been changed?

In ReactiveUI, setters are always 100% boilerplate, you should never be doing anything in a property setter other than calling RaiseAndSetIfChanged. Instead, use WhenAny in the constructor, which will automatically suppress dupes for you

[glennawatson]

I would say the only scenario I found that is valid is the F# implementation using it to pass to its functional chain, which leaves more justification 'leave it as it is' TM.