Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

  (email not shown publicly)
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Tuesday September 29, 2009
04:00 AM

Multiple Inheritance and Exporter

[ #39691 ]

We already know that multiple inheritance is bad. So I'm not surprised about the reported multiple inheritance Exporter bug. What I am surprised about is that this behavior still surprises people. Clearly more education is needed. So here's some education for you:

Multiple inheritance is wicked and wrong and you shouldn't use it!

It used to be the case that you might be able to make a weak argument for this abysmal practice. With roles, I'm hard-pressed to think of any excuses. Stop using multiple inheritance.










Given how many times I warn against absolute terms like "never" and "always," I'm on thin ice here.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • I maintain an ancient codebase (uses Class:DBI and Exporter heavily) and ran into this recently. I had a hell of a time tracking it down and ended up just fixing it by not inheriting from Exporter. It was all pretty frustrating.
  • You admit you are on thin ice, so allow me to pull you back before you break through.

    Multiple Inheritance is a fundamental OO concept.

    The only programming language I know that *safely* implements it is Eiffel.

    Most people who get in trouble with MI don't realize the fundamental danger of method name conflicts, and how they must be resolved. That is the issue with the bug you reference (not in Exporter after all, but with Class::Accessor::Fast).

    OOSC2 (Meyer, 1997) highlights two "interesting issues" a

    • Roles is not an alternative to the design concept of Multiple Inheritance

      What's the design concept of Multiple Inheritance?

      The problem with OO as it's usually conceived is that classes are used both for their responsibilities -- which tends to make the classes larger -- and for behavioral reuse (frequently via inheritance). When you want to share behavior in a procedural module, we know that it's usually a bad idea to have modules automatically pollute your code with a bunch of functions you didn't ask to import. You should ask for them explicitly (via @IMPORT_OK if using Expo

  • ...why would you use Exporter when Sub::Exporter is right there? I mean, it's practically a parameterized role itself...