I believe that you are focusing on the wrong priority. To me, it is an example of 'premature optimisation'.
SetValue() has 2 main tasks
- set the backing value from the argument supplied
- update data bindings (NotifyPropertyChanged)
In my opinion, the task 1 must
be the 1st priority and must always
happen. Otherwise SetValue() is broken.
You cite the example where the backing type is string. String is an immutable type, whereas most user types are mutable. Also how often is your example likely to happen in real scenarios?
Which is the worse outcome after calling SetValue():
- NotifyPropertyChanged() is called when it isn't absolutely necessary?
- The backing value is not the value the calling code expected.
Even if you are really upset by the 'extra' call to NotifyPropertyChanged(), why not provide an overload of SetValue() for strings?
In any case, when I supply an object to SetValue() , I require that object to be returned when I call GetValue().
As an aside, I tested the CSLA.SetProperty() [equivalent to Catel.SetValue()]. In every case SetProperty() set the backing value from the argument.