The Challenge

For example, consider a text templating framework, which might be separated into several elements:

• a base class, which provides methods to convert marked-up text into runnable code,
• an extension which enhances security by runing the code in a Safe compartment,
• an extension which feeds output through an HTML-escaping filter, and
• an extension which records internal profiling data for benchmarking purposes.

(See Text::MicroMason for an example of this design.)

A Bad Approach

                    +---------+
                    |   Base  |
                    +---------+
                         |
       +-----------------+-----------------+
       v                 v                 v
  +---------+       +---------+       +---------+
  |Benchmark|       |  Filter |       |   Safe  | @ISA=qw(Base)
  +---------+       +---------+       +---------+

The well-known problem with this implementation appears when you want to combine several features:

                    +---------+
                    |   Base  |
                    +---------+
                         |
       +-----------------+-----------------+
       v                 v                 v
  +---------+       +---------+       +---------+
  |Benchmark|       |  Filter |       |   Safe  | @ISA=qw(Base)
  +---------+       +---------+       +---------+
                         |                 |
                         +--------+--------+
                                  v
                           +-------------+
                           | Safe_Filter | @ISA=qw(Filter Safe)
                           +-------------+

This is the dreaded "diamond inheritance" problem: if Base provides a compile() method, which Filter and Safe each override to perform additional actions before or after calling SUPER::compile(), how can we ensure they are all called in the correct sequence?

A Good Approach

Indeed, composition is an underutilized design technique, and there are many times when inheritance is not the best tool to use. But of course, in Perl there's more than one way to solve this problem, one of which is facilitated by this distribution.

A Different Approach

  +---------+       +---------+       +---------+       +---------+
  |Benchmark|       |  Filter |       |   Safe  |       |   Base  | 
  +---------+       +---------+       +---------+       +---------+
                         |                 |                 |
                         +-----------------+-----------------+
                                           v
                                    +-------------+
                                    | Safe_Filter | @ISA=qw(Filter 
                                    +-------------+     Safe Base)

However, in this condition our mixin classes can't call SUPER methods at all! Instead, another redispatch mechanism is needed, one that is able to back-track through the inheritance tree and explore other branches. (See NEXT for such an implementation.)

The order in which mixins are stacked is significant, so the caller does need to have some understanding of how their behaviors interact. For example, you'd typically want to ensure that the Benchmarking mixin was the first in the chain, so that it could time everything later in the sequence.

This Distribution

To generate an object with some combination of mixins, you first use a mixin factory to generate a mixed class. If a class with that combination of classes has already been created, it is reused. You can add a factory method to your base class, create a separate factory object, or inherit to produce a factory class. (See Class::MixinFactory::Factory.)

To allow mixin classes to redispatch to subsequent classes, all mixed classes also inherit from a class which provides a NEXT() method. (If you would prefer, your mixin class can alternately use the AUTOLOAD solution provided by the NEXT::ACTUAL module from CPAN, or any other equivalent re-dispatch mechanism.) (See Class::MixinFactory::NEXT.)