From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Computing (Rated Start-class, Mid-importance)
WikiProject icon This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
Start-Class article Start  This article has been rated as Start-Class on the project's quality scale.
 Mid  This article has been rated as Mid-importance on the project's importance scale.
WikiProject Computer science (Rated Start-class, Low-importance)
WikiProject icon This article is within the scope of WikiProject Computer science, a collaborative effort to improve the coverage of Computer science related articles on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
Start-Class article Start  This article has been rated as Start-Class on the project's quality scale.
 Low  This article has been rated as Low-importance on the project's importance scale.

Confusing analogy[edit]

The bowl and ingredient analogy is confusing—Preceding unsigned comment added by (talkcontribs) 14:53, 2 June 2004

Are mixins bad?[edit]

I always wondered: are Mixin's "bad"? I'm sure the proper answer is that they're useful in some scenarios, but detrimental in others. What should I look out for? What are similar paradigms that get mistakenly used as Mixin's? I don't want to suffer from Golden hammer syndrome, if there's something that answers the problem better... --Eddie Parker 13:19, 2 May 2005 (UTC)

That depends on the definition of "bad". We should well-define the problem. For me, and I come from Ruby, I feel that modules (which provide the mixins for ruby) are basically crippled classes. As thus, they are limited and put a constraint on the programmer. I myself would favour a more open-ended nature and no class/module distinction, and instead specify behaviours on the objects rather than a class/subclass + mixin structure, which always felt awkward to me. (talk) 00:51, 15 December 2011 (UTC)


Link to Flavors needs a substantive page.—Preceding unsigned comment added by (talkcontribs) 22:42, 18 June 2005

Error in "Comentary"[edit]

Inheritance can indeed be used to refactor common behavior, so mixins are just another way of getting the same functionality, AFAIK. (*)

Well, CLOS generic functions allow multiple dispatching, but I don't know if this has something to do with mixins... Maybe it cannot be donne (except for the trick in Visitor) with the other sintax?

(*) Mixins add the benefit of being suitable for some aspect-oriented programming. This is because they can refactor methods from classes that have nothing in common (so it would be a bad practice to make them inherit from a common base). This is also true with the very similar way of ArtScript for defining class attributes. Anyway I wonder wether the benefits of AOP which mixins bring couldn't be reached using multiple inheritance...



Could someone familiar with this concept provide a simple code example? John (Jwy) 18:22, 1 April 2006 (UTC)

I added one for python. Cburnett 03:35, 26 June 2007 (UTC)

Misleading and incomplete[edit]

I've just accidentically stumbled into this article, and I get the severe feeling that it is misleading and incomplete. Most importantly it doesn't really give substantial information, what a mixin is. Then, it is too fixated on specific programming languages. Using mixins is a a programming style, which by and large can be used in nearly every programming language. Just google for Mixin+C++ to get a hint. E.g. Smaragdakis and Batory.

I only have time for this notice right now, but I'll have a try at the article in the future.

Pjacobi 12:30, 12 April 2006 (UTC)

Yeah, I'd also like some elaborations. 5 years later the above message, I read this and still have no clue on what those things are. Reading this page or not is pretty much the same. It's so vague I don't even have an idea on what I'd like to know more!
MaxDZ8 talk 18:06, 9 September 2011 (UTC)

Maybe I'm being dense but this article doesn't describe what problems mixins are supposed to solve? It's funny that the very fisrt paragraph is all about the history of simula in the 70s or something instead of some clear and non vague reason for the existence of this concept (seperately from interfaces and multiple inheritance I mean).

The way I understand it if B inherits A, C inherits A and you attempt do to multiple inheritance like in D inherits B and C, then if B and C can be instantiated (have a constructor) you either have to somehow choose how the A part in D will be constucted (which constructor to use), or have two copies of A in D. So mixins basically say that B and C can't be constructed like that, they can't exist on their own with their own A, so you just put an A part and complete the hierarchy. — Preceding unsigned comment added by (talk) 17:59, 12 September 2011 (UTC)

I read this article, several times and I still do not have a clue as to what it is talking about. I suggest an example using a fairly well known language such as Java or C++ or C# rather than Lisp. The first part of this topic should provide a more layman's type of description of a mixin then follow that up with a section of esoterica, clearly labeled as such, so that those of us who just want the basic concept can get that and move on. 08 November, 2011. — Preceding unsigned comment added by (talk) 21:58, 8 November 2011 (UTC)

I think the #1 reason it is confusing is that it mistakenly uses the word "mixin" for both the class in which the composition takes place (in the first sentence) and also for the classes which implement the orthogonal functionalities to be composed (in the Python example). It has other flaws aswell. I recommend putting some warning ontop that it is of low quality (I have seen such on other pages). — Preceding unsigned comment added by (talk) 16:48, 3 January 2014 (UTC)

Definition and implementation - Missing Javascript[edit]

Given the popularity of Javascript, it should probably get added to the list of languages that use Mixin for object creation. In Javascript, you define the class and add the methods afterwards. You can add methods new at runtime. data64 17:59, 24 September 2006 (UTC)

Um, javascript doesn't have classes. The best you can do is is copy in methods from another object but you have to do that manually. Cburnett 03:22, 26 June 2007 (UTC)

PHP and ColdFusion[edit]

I removed PHP. How can you have mixins in PHP when PHP only has single inheritance? That gives you no room to "mix in" the mixin class. The best you can do is declare a class as abstract and inherit from there, but how can that be a "mixin"? Cburnett 03:20, 26 June 2007 (UTC)

Maybe in this way or this way? oc666 (talk) 08:00, 5 May 2010 (UTC)

I also removed ColdFusion. Again, like PHP, it does not have multiple inheritances so how can mixins work? Cburnett 23:35, 27 June 2007 (UTC)

Did you know that using of mixins is also possible in languages that support only single inheritance? Take a look at Ruby or Java. Ruby uses modules for that purpose ( and Java leverages the power of Aspect-oriented programming (as someone noticed in Commentary section). —The preceding unsigned comment was added by (talkcontribs).
That link gave me a 'file not found' error. Can you give an example of how to use a mixin with PHP to achieve something like my python example (I know, PHP doesn't have threads but something analogous would be fine)? Cburnett 03:52, 9 July 2007 (UTC)
Thanks, I have corrected ruby link. Unfortunately I didn't know PHP at all (look at I just pointed out that usage of mixins is also possible in languages that support single inheritance only. —The preceding unsigned comment was added by (talkcontribs).
I appreciate the links. The PHP example is an ugly, ugly hack. PHP does not support mixins and the method used in your link is dynamically creating classes via eval() calls. The Ruby example is a step in the right direction (classes are not dynamically created). My qualm with that method is that the mixin is no longer a class like this article defines a mixin as ("a mixin is a class"). It's merely including functions that pretend they are in a class. The WhoAmI function references self when it is clearly not in a class (in this way it is a true mixin because it definitely cannot stand alone).
At the end of the day, I don't have a strong problem including Ruby (perhaps some of the other languages listed also do "mixins" in a similar way) but I do with PHP. In PHP, functions are not first class objects therefore your only route is to dynamically create classes to work around the languages inability to do it the "Ruby way" or a more literal way like Python.
I would like to see the list split up into "the real way with multiple inheritances of classes" and "the ruby include kind of way". Cburnett 13:39, 9 July 2007 (UTC)
Mixin will be a core-feature in PHP 5.4. [User:SimonSimCity|SimonSimCity] 13:03 31 Oct 2011 (UTC) — Preceding unsigned comment added by (talk)

This but not that[edit]

How can a programmer in mixin enabled programming languages decide which methods/attributes of a superclass shall be mixed in to the to developed subclass and which not? --Abdull (talk) 15:57, 8 February 2008 (UTC)

The exact mechanics depend on the language. Mixin is more like a design pattern. You have to decide which functions perform what parts of your task and then you implement just certain functions differently to get different behavior.
In the python example the ThreadingMixIn class implements the process_request method. This method creates the new thread that handles the rest of the request in that new thread. The ForkingMixIn, instead, forks another process to handle the rest of the request. Cburnett (talk) 19:27, 8 February 2008 (UTC)


"However, mixins introduce their own set of compromises."

What compromises? What compromises of multiple inheritance do mixins avoid?

Fresheneesz (talk) 17:50, 26 April 2010 (UTC)


The paragraph starting with "A mixin can defer definition..." in the introduction states properties of mixins that are not general; they probably occur in a specific language that the writer had in mind. I think that it should not appear in the intro. AmirOnWiki (talk) 15:52, 3 June 2010 (UTC)

"C# Mixins" references do not support the claims[edit]

Under Commentary:

... C# 3.0 has the ability to mimic mixins.[5][6][7]
[5] Implementing Mixins with C# Extension Methods
[6] I know the answer (it's 42) : Mixins and C#
[7] Mixins, generics and extension methods in C#

In my reading, references 6 and 7 conclude that mixins are NOT supported by C#. Reference 5, in my opinion, falls short of showing support for mixins. —Preceding unsigned comment added by (talk) 22:34, 8 February 2011 (UTC)

C++ is missing[edit]

C++ does support mixins for example with virtual inheritance, where the top corner is the interface, the middle classes are the mixins, and the bottom class is the one you build up with the lego-like mixins. Agree to add it? Dgutson (talk) —Preceding undated comment added 06:30, 27 May 2011 (UTC).

Object Pascal / Delphi[edit]

What about "Class helpers" in Object Pascal resp. Delphi, can they be seen as an implementation of this concept? — Preceding unsigned comment added by (talk) 09:28, 15 February 2012 (UTC)

Bad Definition of a Mixin[edit]

A Mixin class is not a class that is a combination of methods from other classes. It is simply a class that is meant to to be inherited by some class that is also inheriting from one or more other classes and is meant to provide a specific service to its clients. Thus it is its clients that are using multiple inheritance (and are thus "a combination from other classes", but I would choose not to express it in these terms) -- but they are not the Mixin classes. Raaronson (talk) 23:10, 5 January 2014 (UTC)