Stories
Slash Boxes
Comments
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

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • 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 Exporter). Thus, we generally find it's better to allow people to pull in a subset of desired behavior (e.g., you usually don't want all of the functions which List::Util or Scalar::Util provide). Thus, behavioral reuse implies that we want smaller amounts of code in the behaviors we're sharing.

      As a result, classes have long had a well-known larger/smaller tension in their dual nature of responsibility/reuse. The only reason I've ever seen anyone use MI is for behavioral reuse, but since it's constantly abused and so easy to get wrong and trivial to create examples which are difficult, if not impossible, to work properly under MI, why bother? There's an excellent reason why many excellent language designers forbid MI. They want to separate the responsibility and code reuse nature of classes. Java tried to do this with interface. Ruby tried to do this with mixins (a technique originally found in a LISP variant). If so many experienced language designers are trying to find a better way to handle this problem -- a problem which we've struggled with for FOUR DECADES -- then why on earth should we mere mortals suggest such a buggy and fallible technique? Since there are clearly superior alternatives available (roles [slideshare.net], in this case), why not use them? You get all of the benefits of MI and none of the drawbacks.

      I repeat: roles give you all of the benefits (and more!) of multiple inheritance and none of the drawbacks. So why cripple yourself and others? Roles are easy to get right and multiple inheritance is easy to get wrong. It's a no-brainer.