Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling
 
PerlMonks  

Implementing a Mixin Class

by Belgarion (Chaplain)
on May 31, 2004 at 15:46 UTC ( [id://357809]=perlquestion: print w/replies, xml ) Need Help??

Belgarion has asked for the wisdom of the Perl Monks concerning the following question:

Has the community reached a consensus on the preferred way to implement a mixin class? After reviewing some common modules, I have come across at least three different ways of implementing a mixin class.

Using Standard Perl Inheritance
A class like Class::Accessor uses the Perl inheritance mechanism to bring their methods into the package name-space. If you want to bring in more mixin classes, you need to add them to your use base qw(..) statement.
Customized import And Manipulation of the Symbol Table
Unlike Class::Accessor, Class::Trigger uses a customized import function to manipulate the package's symbol table to add the new methods.
Export methods into Package Name-Space
Finally, a module like Class::DBI::FromCGI uses Exporter to export the method names directly into the package's name-space.

There may be other ways of implementing a mixin class. Are any of the methods listed above the preferred way, or is there another method altogether?

Replies are listed 'Best First'.
schwern uses mixin
by PodMaster (Abbot) on May 31, 2004 at 16:53 UTC
    use mixin;#)

    MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!"
    I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README).
    ** The third rule of perl club is a statement of fact: pod is sexy.

      What benefits would using the mixin module have? It doesn't look very different from simple Exporter approach. If it has a benfit, I would think it's that you are declaring "Hey! A mix-in class is being used here!". And maybe that's enough benfit to make it worthwhile.

      In particular, could anyone who used the mixin module comment?

      I maintain a mix-in module myself, using the Exporter method: CGI::Application::ValidateRM.

Re: Implementing a Mixin Class
by adrianh (Chancellor) on May 31, 2004 at 16:08 UTC

    I don't really think a consensus has been reached. I'd probably use your first multiple-inheritance based option myself.

    Your second and third options are really the same thing. Exporter is just a standard mechanism for supplying import based symbol table fiddling.

    Perl 6 is looking to generalise "mixin" type behaviour a bit with Traits (called 'roles' in Perl 6). You might want to take a look at some of the Perl 5 implementations of this strategy (Class::Role, Class::Roles, Class::Trait).

Re: Implementing a Mixin Class (please explain?)
by Seumas (Curate) on Jun 01, 2004 at 00:18 UTC
    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.
        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.
      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.

      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
Re: Implementing a Mixin Class
by tilly (Archbishop) on Jun 01, 2004 at 01:38 UTC
    "The community" has not even reached a consensus on whether implementing mixin classes is an adviseable thing to do, let alone what the best way to do it is.
Re: Implementing a Mixin Class
by EdwardG (Vicar) on Jun 01, 2004 at 08:15 UTC
    <heresy>

    As far as I can tell, mixins are yet another artifact of the mistaken belief that modelling The Real WorldTM inevitably leads to better programming constructs.

    The OO pioneers, struck by the apparent universality of abstraction and specialisation, and lured on by the taxonomical success of the biologists, had one key success, the creation of a powerful meme; the notion that object oriented methods must be pure in their conception, untainted by so called procedural thought.

    This inevitably leads us to the current vogue; that to claim legitimacy, every new OO invention must have an appealing analogy in The Real World.

    And mixins, by all accounts having their origin in an icecream store, and being as they are inherently an introduced novelty, are an indication of the extent to which the theorists are willing to embrace the farcical for the sake of conformance with the aforementioned meme of purity.

    Mixins allow the would-be purist to program however they damn well please, all the while intoning the virtues of purity with a straight face.

    </heresy>

     

      And mixins, by all accounts having their origin in an icecream store, and being as they are inherently an introduced novelty, are an indication of the extent to which the theorists are willing to embrace the farcical for the sake of conformance with the aforementioned meme of purity.

      That's not really fair. The name has its origin in an ice cream store (as did other puns in the Flavors language, like having 'vanilla' as the name of the base class), but I don't think anybody can seriously say that this is any sort of real-world metaphor for the language.

      Mixins are just one way of decomposing a system. Sometimes appropriate and sometimes not.

      Exactly, I'm usually stricken with confusion when I see the latest in OO design or features being pushed -- design patterns were sometimes obvious but sometimes overblown -- often just ways of making bad design more politically correct. Ah, yes, it's a Drunk Hippy Inspector Pattern! Or when they cover for feature-creep or inheritance-tree-sprawl (aspect-oriented development). Mixins are just another, when we really have to ask, are we just coding this to thump our chests or is there a simpler, easier, way? Usually there is.

      If it looks like I'm bitter, then yes, I am -- I'm tired of "architects" without a clue as to how to write maintainable code getting paid 3x as much as the folks that actually do real work, and all the time they are making easy things harder to maintain, not easier. I went to school thinking software architecture was the coolest thing ever. Reality has taught me otherwise. The need for new OO-isms (mixins, the need to quote GoF daily, AOD, reflection, etc) are usually a coverup for a basic design flaw somewhere in the program. Keep it simple!

        I understand your anger, brother.
        Think TIMTOWTDI about it, even if you got the feel of nonsense coming up: Let everybody build their own stylish seven-wheel-bycicle because innovation sometimes needs to walk the strangest paths: It might even lead to something that will do you good in the end.
        You're allowed to snigger at all the mishaps on the way =)

        Cheers, Sören

Re: Implementing a Mixin Class
by cees (Curate) on Jun 01, 2004 at 13:00 UTC
    There may be other ways of implementing a mixin class

    There is of course (this is perl after all). It follows the same lines as the Namespace mungers you list above, but the Time::Piece::MySQL uses a slightly different method by placing 'package Time::Piece;' directive in the code, which ends up writing it's methods directly into the Time::Piece namespace.

    Maybe not the best way of doing it, but it is simple, and it works...

    - Cees

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://357809]
Approved by Old_Gray_Bear
Front-paged by Enlil
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others wandering the Monastery: (3)
As of 2024-03-29 14:52 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found