Proxy or Calculated Property

Is your feature request related to a problem? Please describe.

Shortcoming have been discovered in the property system related to dependent properties and properties calculated from others. These same deficiencies existed in WPF so this is nothing new. However, there is an opportunity to solve this better in the future.

Describe the solution you’d like

1. Properties that should change and raise property changed events together.
   • First noted here by @grokys where SelectedItem and SelectedIndex, if styled properties, have some synchronization issues.
   • This was apparent after the switch from DirectProperty to StyledProperty. With DirectProperty full control is given in this case to raise events together after both properties are internally handled.
2. Properties that alias other properties (proxy)
   • This came up in the past to basically support some properties for compatibility with WPF that just alias existing properties with a new type and/or name.
     • This includes properties that are calculated directly from another
     • For example WPF/WinUI’s Visibility property could be an alias of IsVisible.
     • Another example is WPF/WinUI’s ActualHeight and ActualWidth property could be an alias of Bounds. #11325
   • Another use-case that was discussed in the past is to allow us to fix API mistakes while keeping compatibility. Currently it is very difficult to rename a Styled/DirectProperty. With such a mechanism we can rename a property then keep an old, obsolete proxy/alias property (with the original name/type) around for compatibility until the next major version.
   • https://github.com/AvaloniaUI/Avalonia/pull/6836#pullrequestreview-797475570. “I guess BorderBrush and BorderThickness could be “aliases” for BorderPen.Brush and BorderPen.Thickness but that might raise complications?”

Describe alternatives you’ve considered

None, these are issues that haven’t been solved in WPF or WinUI and weren’t fully solved with DirectProperty either.

Additional context Add any other context or screenshots about the feature request here.

[robloo]

@rabbitism, The WPF compatibility considerations were an example. There may be other use cases for this concept.

That said, avoiding ambiguity and duplication is important so I see your point there.

[maxkatz6]

I would also add an inherited readonly properties support. Or, readonly styled properties. Use case - ActualThemeVariant, which right now implemented as an inherited property, and technically can be changed by the user (using SetValue directly).

It alternatively can be a computed property as well. But it would require adding some inheritance functionality to the same.