Most OO hackers say that multiple inheritance is generally evil. You should consider redesigning your system so that you are using composition and delegation instead of MI, and life would be better for you and the people who have to maintain your code.

As I tried to explain in my earlier node, I agree with the central thrust of this position, but think of it as "generally" true rather than a hard-and-fast rule. (One could say that AUTOLOAD and string evals were "generally" evil, or at least "sometimes" evil, but of course that's just one layer of the onion, and everyone recognizes that there are cases in which those techniques are perfectly valid.)

I explicitly did consider using composition and delegation instead of multiple inheritance, but decided that in this case mixin classes would be a more straightforward mechanism. A base class and collection of mixin classes is hardly a wild and wooly case of MI: there's explicit sequencing of classes, no diamond networks, and a well defined base class.

In the specific case of Text::MicroMason, one of my goals was to keep the base class simple. (If it grows significantly I might have to take "Micro" out of the package name.) I certainly understand why HTML::Mason has separate classes for each activity (resolver, lexer, assembler, compiler, etc), but given the deliberately small scope of the MicroMason distribution, I selected this other technique, in which activity is a method which can be overridden by subclasses.

So, yes, I know that in the general case MI is "considered harmful", but is there something about this particular implementation that strikes you as more evil than the average? Of course, if you have comments about specific ways in which my life could be better, I'm open to hearing them...