Proposal/Discussion: Stateful Mixins

[HaloFour]

Tossing this proposal up since a couple of people have mentioned it. It builds on default interface methods (which resemble traits) to add stateful mixins to the language. Consider it spaghetti at the wall for the purposes of discussion fodder.

Proposal

I propose the ability to declare mixin types:

public mixin HasName
{
    // OMG! State!
    string _name;

    public string Name
    {
        get => this._name;
        set => this._name = value;
    }
}

This is converted into an interface with a nested struct representing the state and a protected member for accessing the state from within the mixin:

[System.Runtime.CompilerServices.MixinAttribute]
public interface HasName
{
    string Name
    {
        get
        {
            ref Mixin @this= ref this.State;
            return @this._name;
        }
        set
        {
            ref Mixin @this= ref this.State;
            @this._name = value;
        }
    }
    
    protected ref Mixin State { get; }

    public struct Mixin
    {
        public string _name;
    }
}

When a class implements the mixin the compiler will automatically create a field of the nested state structure and explicitly implement the member necessary to retrieve the state:

public class Foo : HasName { }

// compiler generates

public class Foo : HasName
{
    // use some unutterable name here
    private HasName.Mixin _mixinState;

    // assumes private explicit implementation of protected interface member
    ref HasName.Mixin HasName.State => ref _mixinState;
}

The implementing class can optionally override the default members, as they could with any interface:

public class Bar : HasName
{
    public string Name { get => "BAR!"; set { } }
}

Questions:

1. Is this the apocalypse?
2. New keyword mixin or just continue to build on interface?
3. Should an implementing class be able to access the mixin state directly?
4. How to deal with the "diamond problem"?
   • For method implementations this should be mitigated by the decision applied for default interface methods.
   • The question of state is a different problem, leading to:
5. Should multiple mixins share state?
6. How can a mixin extend another mixin?
   • What if two mixins different mixins inherit from the same mixin?
7. Is any of this really necessary or could "stateful" traits really be a convention like the above that a developer could apply themselves?
8. Are mixins useful if the default members are not visible in the implementing class?

[HaloFour]

The visibility decisions around default interface methods would immediately complicate this proposal as those members would not be accessible directly from the class:

var foo = new Foo();
var name = foo.Name; //error CS1061: 'Foo' does not contain a definition for 'Name'

Unless the compiler behaved differently in this case by generating public members to implement the interface I don't know how much use this proposal would really be:

public class Foo : HasName { }

// compiler generates

public class Foo : HasName
{
    private HasName.Mixin _mixinState;
    ref HasName.Mixin HasName.State => ref _mixinState;

    // compiler generated public member delegating back to default implementation
    public string Name {
        get => base(HasName).Name;
        set => base(HasName).Name = value;
    }
}

[rikimaru0345]

Can you elaborate on your thought in point 4 ? What do you mean by "I assume that this will be answered and solved with default interface methods." ?

As far as I know it won't be solved with default interface methods, because they won't be able to have any state (exactly because of the diamond problem), right?

Also, can we find at least one really specific usecase for this? I'm sure there are but I can't think of any off the top of my head right now.

[yaakov-h]

@rikimaru0345 INotifyPropertyChanged is a wonderful use-case.

[HaloFour]

@rikimaru0345

That's a very good point. I was thinking of the question of the method implementations, but state poses another problem entirely. I've updated the list of questions to include the problem of state.

I agree, a list of use cases would certainly help the discussion.

[rikimaru0345]

@yaakov-h

Interesting.
Mixins add new functionality to a class they get mixed into.
However INPC requires changes to existing properties. It requires they being modified to include the call to NPC when a property changed.

How would mixing accomplish that?

I was always under the impression that code generators are the way to go to "solve" INPC and related problems once and for all, as they can change things and inspect their modification-target.

If mixins would solve this as well that would be really interesting, as that would mean they would also potentially solve the gigantic list of scenarios that was created for code generators.

If that is really the case, then we could simply take a look there and "steal" some more example use cases from there :)

[ghord]

@rikimaru0345 I think they want to add INPC mixin that provides PropertyChanged event (our state) along with usual RaisePropertyChanged([CallerMemberName] string property = null) and/or SetField<T>(ref T field, T value, [CallerMemberName] string property = null) implementations. currently you can only do that using base class which is not ideal.

You would still have to manually implement properties.

[dotnetchris]

I support mixins, this gives us semblance of being able to inherit from multiple types without introducing all the insanity that true multiple inheritance creates.

The most common scenarios I would leverage this are for "core" aspects of my entities. Id, CreatedAt, UpdatedBy. Currently I'll end up with a bunch of interfaces to roughly emulate what @HaloFour proposed, and then several base classes of permutations of the interfaces [Id, Created], [Id, Created, Updated], [Created, Updated] note the lack of Id on the last one. I can't easily split that up, with multiple inheritance each of Id, Created, and Updated would all be discrete types and you would inherit from all of them.

[AustinBryan]

So can a mixin have methods? If not, that'd make them the opposite of an interface, right? Then you could take a class that already has a parent and inherit from IFoo and MFoo and together that'd be the same as inheriting two classes so wouldn't that cause problems?

I may just have all of this wrong though, I'm not sure I get the concept or usage.