Greetings brethren. Some of you may remember my comments and questions from last month about making effective use of multiple inheritance for run-time selection of mixin classes, in response to which I received some helpful input.

I've continued working on ideas drawn from those discussions and have assembled a reusable solution to this problem, and I'd like to run it by the monastery for feedback before posting it to CPAN.

The new package provides a class factory that creates new packages that inherit from multiple classes, and includes a method to allow mixin methods to redispatch to the base class functionality.

I've tentatively named it "Class::MixinFactory" in hopes of capturing the salient details -- it generates new classes by assembling mixins -- but would welcome alternate suggestions.

A simple use might look the following:

package MyClass; use Class::MixinFactory -hasafactory; sub new { ... } sub foo { return "Foo Bar" } package MyClass::Logging; sub foo { warn "Calling foo"; (shift)->NEXT('foo', @_) } package MyClass::UpperCase; sub foo { uc( (shift)->NEXT('foo', @_) ) } package main; my $class = MyClass->class( 'Logging', 'UpperCase' ); print $class->new()->foo(); # Calls MyClass::Logging::foo, MyClass::UpperCase::foo, MyClass::foo

I've posted a draft of the documentation online.

There are a number of related modules on CPAN, but none with quite the same mix of functionality:

Feedback would be welcome; some of the questions I'm considering are:

Replies are listed 'Best First'.
Re: Stacking Mixin Classes at Run-time with Class::MixinFactory
by Anonymous Monk on Nov 16, 2004 at 18:18 UTC
    Using the proper ice cream store real-world analogy, Mixins come from candy companies, not factories. I suggest you amend this. Also, a Factory for a Factory is usually called a GeneralContractor, or maybe a ConstructionCompany. We don't need to check if something has a factory, since, well, we know some things always come from factories (like car parts).

    <quote> Effective use of multiple inheritance for run-time selection of mixin classes </quote>

    Seriously, can you justify a real world example where this cannot be replaced with a simpler concept? IMHO such complexities are a sign the code/design needs refactoring to make it simpler...not more complex.

      Seriously, can you justify a real world example where this cannot be replaced with a simpler concept?

      Of course multiple inheritance CAN be replaced by decomposition and delegation -- for that matter you could do it all without method calls, or in COBOL -- the question is whether your code would end up being better as a result.

      My contention is that controlled use of multiple inheritance is a reasonable technique for a developer to use, and more specifically that this implementation is a workable solution for cases where you'd like to extend an object through subclassing, and need the ability to use several subclasses at once.

      The example I was using was from the real world -- Text::MicroMason. Using stackable mixins lets users select which features they want to enable, with relatively little overhead... If you see a better way to handle this, patches would be welcome.

        -- for that matter you could do it all without method calls, or in COBOL -- the question is whether your code would end up being better as a result.
        Straw-man. Of course Fortran is the way to go.
Re: Stacking Mixin Classes at Run-time with Class::MixinFactory
by simonm (Vicar) on Nov 29, 2004 at 23:00 UTC