Proposal: Unseal all the things

[ryandemopoulos]

Summary

Rationale

• Enable developers to subclass a wider range of our classes/controls (longstanding request from our community)

Scope

Capability	Priority
Unseal all, or at least nearly all classes in the framework	Must

Important Notes

• To WinUI community: Internally our MSFT XAML team has been planning to do this. I'm opening this issue to encourage additional conversation / interaction / questions about this work.
• This work will require WinUI 3, so I've added the needs-winui-3 label to the issue.

[SavoySchuler]

This is a fantastic proposal, @ryandemopoulos! I can't wait to see what the community can create with this barrier removed.

[huoyaoyuan]

Do we need some mechanism to allow custom unsealed controls?
Currently, we can create a control into an unsealed .NET class, and only .NET dependencies can derive from it. Given that most client UI codes are written in .NET, this is not so painful.

[MikeHillberg]

What you can't do today is subclass the built-in types that are sealed. For example you can subclass TextBox, but not TextBlock.

[crhaglun]

Does this imply that <Style.TargetType> will need to start respecting subclasses? (Or should that perhaps be a separate feature request?)

[MikeHillberg]

@crhaglun, changes to Style.TargetType behavior would be a separate feature. Currently you can set the TargetType to a base class and use it with a derived type, for example you can set a ToggleButton style onto a CheckBox. But you can't define an implicit ToggleButton Style (defining it in a ResourceDictionary without a key) and have it automatically be picked up by CheckBox instances in that tree.

[crhaglun]

@MikeHillberg right, and that's actually something I ran into today when working with the Photos app. There's a couple of custom controls that derive from AppBarButton that, when placed in a CommandBar, does not look anything like the vanilla AppBarButtons in the same CommandBar :-)
Turns out the CommandBarRevealStyle has a local <Style TargetType="AppBarButton" BasedOn="{StaticResource AppBarButtonRevealStyle}" /> which of course does not apply on controls deriving from AppBarButton.
If all controls become unsealed, wouldn't this become a much more common class of bug?
Or am I actually looking at a bug in the CommandBar template?

[MikeHillberg]

@crhaglun, yes, more controls will have the opportunity for this problem. If you're interested in this it's worth opening a separate issue. We intentionally don't take class hierarchy into account with implicit styles, for fear of mysterious style application. WPF has a style aliasing feature which would be interesting to add here.

[verelpode]

I agree and want this unsealing proposal to proceed, but I also think it'd be worthwhile to consider this alternative proposal to allow derivation of sealed classes:

Proposal: Extension/derivation of sealed classes (dotnet/coreclr#26465)

[verelpode]

On second thought, forget my above-mentioned proposal, because it falls into the domain of the .NET Foundation and this means the proposal becomes enormously difficult and time-consuming for non-technical reasons. This enormous non-technical difficulty and giant test of patience/determination can be completely avoided by taking the easier path of unsealing the classes.

[verelpode]

Unseal all, or at least nearly all classes in the framework

OK, not every class will be unsealed, says the proposal. Whenever the unseal decision for any particular class is borderline or difficult to decide, I'd like to suggest that "partial unsealing" be considered. The policy could be that borderline cases should fall in favor of "partial unsealing" if not full unsealing. I'm using the words "partial unsealing" to mean the following:

Fully sealed:

sealed class MyDerivedClass : MyBaseClass
{
    public override void Method1() { }
    public override void Method2() { }
    public override void Method3() { }
}

Fully unsealed:

class MyDerivedClass : MyBaseClass
{
    public override void Method1() { }
    public override void Method2() { }
    public override void Method3() { }
}

Partially unsealed:

The class is unsealed but every (or many) virtual members are sealed:

class MyDerivedClass : MyBaseClass
{
    public sealed override void Method1() { }
    public sealed override void Method2() { }
    public sealed override void Method3() { }
}

For example, let's hypothetically pretend that the unseal decision for TextBlock is borderline and the final decision is partial unseal. If every member inside TextBlock is sealed, then obviously subclasses cannot override any members, but this doesn't mean that subclassing becomes useless.

The following example class doesn't override any virtual members, but nevertheless succeeds in achieving a goal of making a derived class of TextBlock that auto-shrinks the font size when the TextBlock is resized to a smaller size (just for example). Furthermore, it also succeeds in its goal of adding support for a fictional interface IConvertibleToRichText that allows objects or UI elements to be converted to RichEditTextDocument.

class MyExtendedTextBlock : Windows.UI.Xaml.Controls.TextBlock, IConvertibleToRichText
{
    public MyTextBlock()
    {
        // Subscribe to public event "SizeChanged" defined in a base class:
        base.SizeChanged += this.OnSizeChanged;
    }

    private void OnSizeChanged(object sender, SizeChangedEventArgs e)
    {
        if (this.IsAutoShrink)
            base.FontSize = XXXXX;
    }

    public bool IsAutoShrink { get { ... } set { ... } }

    RichEditTextDocument IConvertibleToRichText.ConvertToRichText()
    {
        return XXXXX;
    }
}

Thus a "partially unsealed" class still supports a useful degree of derivation, albeit with restrictions. So, if partial unseal is also on the table in addition to full unseal, then a wider range of classes/Controls could be subclassable; wider than if only full-unseal is on the table.

[MikeHillberg]

Xaml's surface area is in WinRT APIs, and WinRT today only supports sealing of classes, not members.