Someone care to take a stab at it or point to a resource?
Mixins, together with some other cool D features, like CTFE (compile-time function execution), templates and ability to load external file at compile-time can be used to create DSL compiler which compiles to native code (first to D, than to native, of course).
For example, ctRegex from std.regex [1] (standard library regular expressions module) uses mixins to generate D code in compile-time out of regular expression (and D compiler outputs native code for regular expression matching).
There is also a PEG parser that works at compile-time (reads external PEG grammar and generates parser code) but I cannot find a link at the moment.
Of course, creating DSL parsers is not the only thing you can do with mixins, but they are surly the first to come to mind..
[1] https://github.com/D-Programming-Language/phobos/blob/master...
Some use cases:
- make repetitive code shorter [1]. Think the C preprocessor but after the parsing stage.
- operator overloading is a single template function parameterized by a compile-time string. This more or less requires using string mixins [2].
- [edit] raleks's comment has better examples [3].
Overall string mixins feel a bit dirty but you get used to it. D also has "template mixins" which do not escape parsing prior instantiation.
D mixins are neither like Scala mixins nor Ruby mixins.
[1] https://github.com/p0nce/gfm/blob/master/math/easing.d#L64.
[2] https://github.com/Dav1dde/gl3n/blob/master/gl3n/linalg.d#L2...
The idea of Mix-ins is that an object may have several functional components, like say a printer, a logger, maybe some access controls for user privileges, in addition to the actual class bits. Under a mix-in system, you would write a printer mix-in, a logger mix-in, and an access-control mix-in, and then any of your classes can get that functionality just by including them. Adding this functionality is supposed to be literally as easy as adding a decorator in Python, but in order to do this, they usually need programmatic access to the guts of your class in order to insert themselves. That aspect, allowing mix-ins to make programmatic additions and modifications to a class, are what separates them from other styles of OOP like inheritance and composition (those other styles see this as breaking encapsulation, while mix-ins say the components are still functionally independent).
A traditional (inheritance-based) object system probably won't be able to write these services as independent components without meta-programming, and you usually see mix-in libraries written on top of meta-programming systems (a more limited form is also available via multiple-inheritance). They goal is that they provide one of the more common uses of meta-programming, but in a structured and standardized form, since raw meta-programming (and unrestricted multiple-inheritance) has a reputation for going bonkers pretty quickly. Adding it to a stricter language like C# requires extending the language with a tool, not just writing a library.
You are correct though that the "mixins" in this article are nothing like Ruby mixins.
The final matrix-example from the article shows a pretty neat example IMO.
