http://www.perlmonks.org?node_id=357878


in reply to Implementing a Mixin Class

I have been teaching myself OO Perl (with no prior OO experience of any kind) and while I think I understand what the 'mixin' problem might be based on problems I've encountered trying to build complex sets of intertwined classes, but this is the first time I've seen this term used.

Since I don't see this term elsewhere in a PerlMonks search and it doesn't appear in the index of any of my dozen perl books, could someone provide a clear explanation and description of 'mixins'? What they are, what they're intended to solve and so on?

I would greatly appreciate this.
  • Comment on Re: Implementing a Mixin Class (please explain?)

Replies are listed 'Best First'.
Re: Re: Implementing a Mixin Class (please explain?)
by Belgarion (Chaplain) on Jun 01, 2004 at 01:09 UTC
      Pretty brief description, but... from what I gather, it's nothing more than having a package that contains a bunch of methods that you allow to be exported and then having other classes import them?

      I have a ::Util class I fill with a handful of methods that don't particularly belong anywhere and aren't worth having their own class which I then import into other packages. Is this what is considered a "mixin"?

      Sorry if I come across a bit daft. Using Perl as a first exposure to OOP is brain-damaging.
Re^2: Implementing a Mixin Class (please explain?)
by adrianh (Chancellor) on Jun 01, 2004 at 10:18 UTC
    Since I don't see this term elsewhere in a PerlMonks search and it doesn't appear in the index of any of my dozen perl books, could someone provide a clear explanation and description of 'mixins'? What they are, what they're intended to solve and so on?

    Basically a mixin is a partial-class that makes no sense by itself, but can be "mixed in" to another class to supply additional functionality.

    The classic example is adding borders to different kinds of windows in a GUI framework. You have your normal GUI widgets and have a border mixin that you use to create widget classes that draw their borders. You add the border drawing behaviour to the classes with the mixin.

    So rather than specialising behaviour in a subclass you add additional behaviour with a mixin.

    DIfferent OO languages support mixins in different ways. Some like Perl and C++ have no explicit support and you implement them with other features like multiple inheritance or symbol table fiddling. Other languages like Ruby and Flavors have explicit support for mixin classes.

    The "mixin" terms comes from the Flavors langauge - one of the earliest object oriented languages that ran on Lisp Machines. The name came from the (in)famous ice cream metaphor used by the language (the base class was called 'Vanilla') due to an popular ice cream store used by MIT students - Steve's Ice Cream.

    At Steve's you ordered a code or dish and specified the base flavour and any mixin flavours. You then got a scoop of the base with spoonfuls of mixin flavours on top.

Re: Re: Implementing a Mixin Class (please explain?)
by etcshadow (Priest) on Jun 02, 2004 at 20:42 UTC
    A way of thinking of a mixin is: it's a bundle of functionality that can be implemented on top of another bundle of base functionality.

    For example... if I take every class which has a ->Next() method and a ->Reset() method, then I can build all kinds of additional features, using nothing more than the supplied Next and Reset methods. I can make a greplike operator, I can build loops, etc.

    Anyway, I think that's the key to understanding it: a mixin is a way of making it such that any class which can do X, Y, and Z, can also do P, D, and Q.

    ------------ :Wq Not an editor command: Wq