Where was the design discussion for ObservablePropertyAttribute?

[symbiogenesis]

I was developing Silverlight back in the day, and the tool Fody set my expectations pretty high for the ergonomics of this kind of thing.

To me, the approach that Fody chose is far more intuitive and explicit. It just makes more sense that the property should be the one to have the attribute.

What was the reason for making it based on the field? Was it a limitation of the source generator approach, was it a performance thing, or was it a conscious design decision to promote accessing the field within the ViewModel, or something else?

[Sergio0694]

You can find the original issue and plenty of discussions here: #8. The TLDR is: we'd much rather use properties, but unfortunately C# just doesn't support partial properties yet, so using fields is the best we could do. Assuming C# 12 does get partial properties (see dotnet/csharplang#6420), I do plan to add support for using [ObservableProperty] on properties too, for sure. Hope this helps! 🙂

[symbiogenesis]

Ok, I understand. Source generators do not rewrite any code, but can only add. Fody was more magical than that, for better or worse.

It still feels like partial properties aren't optimal, and that some other undiscovered pattern exists that would not require a language modification or overly magical aspect-oriented approach.

If the [ObservableProperty] attribute were switched to use the properties, could we allow [RelayCommand] attributes to simply automatically search for all properties in the same class that have an ObservablePropertyAttribute, and call the PropertyChanged event for all code paths that would hit a setter in a control flow graph?

[symbiogenesis]

I guess that the commands would not have a deterministic control flow knowable at compile time, without rewriting code. I'm just thinking out loud. :)