Permalink
Reply
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
