On Sunday, 25 December 2022 at 15:29:40 UTC, Timon Gehr wrote:

This is exactly true... and it brings to mind an alternate idea: require a non-abstract method must be overridden in a child class.

Consider this:

class Dupable {
__mustOverride("hint message") Dupable dup() { return new Dupable(); }
}

class Child : Dupable {
// if you forgot to override dup, you'd get the wrong type out
// but since the parent had mustoverride, the compiler will tell us
}

error: class Child must override method Dupable dup
hint: hint message

Then it prods them in the right direction and the hint message can tell them to mixin something.

Destroy.

Hi,

Since a few days I think about a new concept called Mixin Methods.
I wonder whether it makes sense to write a DIP or I maybe miss an obvious issue with the concept?

Mixin Methods serves the purpose to enable introspection in class based frameworks by inheritance.

If you look at frameworks like d-unit (https://github.com/linkrope/dunit/blob/master/example.d) or arsd.jni (https://arsd-official.dpldocs.info/arsd.jni.html) they try to solve the issues in different ways.
In d-unit the unit test classes do not have inheritance but each unit test class needs to add a mixin statement mixin UnitTest;.

In arsd.jni there is another concept, the classes inherits introspection by inheriting from the root class and the current class as template parameter:

final class Hello : JavaClass!("", Hello) {
}

The issue with this concept is, all classes inherits from the root class (JavaClass) directly. Inheritance from another child class (e.g. Hello) is not possible.

The concept Mixin Methods can be used like this

import std;
void main()
{
   new Animal().fancyMethod();
   new Dog().fancyMethod();
   new Bulldog().fancyMethod();
}

class Animal {

    mixin void fancyMethod(){
        writeln(__traits(identifier, typeof(this)));
    }

}

class Dog : Animal {}

class Bulldog : Dog {}

Due to the mixin statement, the compiler will copy the fancyMethod into all sub classes of class Animal as method overload.

class Dog : Animal {
// compiler
override void fancyMethod(){
writeln(__traits(identifier, typeof(this)));
}
// compiler
}

class Bulldog : Dog {
// compiler
override void fancyMethod(){
writeln(__traits(identifier, typeof(this)));
}
// compiler
}

As you can see, Mixin Methods works for non static and non final methods. The benefit is, the users just need to inherit from a framework class to inherit the introspection capabilities.

Does it make sense to create here a DIP or do you see any road blocker?

Kind regards
Andre