Hacker News new | comments | show | ask | jobs | submit login
D-style Mixins in C# (jetbrains.com)
32 points by hmert 1667 days ago | hide | past | web | 13 comments | favorite

I read the use case mentioned on the article, wikipedia on mixins and a couple of more articles, I didn't follow what is the use case for mixins?

Someone care to take a stab at it or point to a resource?

Mixins, at least in D, can be very useful when you want to do some meta-programming (at compile-time, of course). They basically allow you to generate code at compile time.

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...

D "string mixins" allow to insert any string as code, usually the result of a compile-time computation.

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...

[3] http://news.ycombinator.com/item?id=4456422

Mix-ins are a style of object-oriented design, in the sense that inheritance, or composition, or generic functions are styles of object-oriented design. They all have the same purpose: logically related pieces of code are co-located and encapsulated, and independent pieces of behavior are decoupled. Ideally, the components of your system should have low interdependency, and be easy to combine.

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.

Normally you'd be right, but D co-opts what the rest of the world accepts as having a well-defined meaning pertaining to OOP to instead represent its hare-brained meta-programming paradigm.

I was confused too when I saw this article on Reddit. Turns out that Mixins in D are similar to Macros and not similar to Ruby mixins. Mixins in an object oriented sense (such as Ruby) are very similar to interfaces in C#.

I wouldn't say that Ruby Mixins are not really similar to interfaces at all, since interfaces represent signature to be implemented by the class and mixins represent implementation.

You are correct though that the "mixins" in this article are nothing like Ruby mixins.

Very good point. Thanks for pointing that out!

Seems like C-style #macros but more powerful in some ways and less powerful in others. It's basically a built in code-generator.

The final matrix-example from the article shows a pretty neat example IMO.

They're like Lisp macros, except instead of generating an AST you're generating text, so it's a huge pain in the ass.

http://c2.com/cgi/wiki?MixIn gives some examples that may help. If the Common Lisp examples seem weird, scroll down to the Ruby ones.

They're like JavaScript's eval, but compile-time and type-safe. The language docs on http://dlang.org says it all.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact