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

use Perl Log In

Log In

[ Create a new account ]

schwern (1528)

schwern
  (email not shown publicly)
http://schwern.net/
AOL IM: MichaelSchwern (Add Buddy, Send Message)
Jabber: schwern@gmail.com

Schwern can destroy CPAN at his whim.

Journal of schwern (1528)

Monday March 19, 2007
10:53 PM

The incredible return of mixin.pm!

[ #32747 ]

I just released mixin.pm 0.05, the first release in, ohhh, five years. I remember coming back from JOIN 2001 after having taken Dave and Andy's "Ruby in a Day" tutorial being all fired up about mixin instead of multiple-inheritance and eventually wrote mixin.pm and then promptly never used it. Its since languished on CPAN with but one lone bug in the queue.

Fast forward five years. I'm trying to convert a large application from Class::DBI to DBIx::Class. CDBI uses traditional inheritance. DBIx::Class uses the C3 method resolution algorithm which I'm not going to try and explain and don't fully understand myself but people say its better and fixes the diamond inheritance problem. Well... "fix" in the sense of "makes not work". When faced with some of the tangled hierarchies in this app it just throws its hands up and dies.

Some of the tangle comes from the fact that in several places an error handling module is inherited from. Boy it would be nice if they didn't have to inherit from it and could instead, somehow... stir its methods in. Whisk. Blend. Puree. Dare I say, mix?

I looked around on CPAN for what the state of the art in mixing is and after a cursory search didn't find anything that wasn't a full blown framework or even more alpha than my own mixin.pm. So I dusted it off and made a quick release to fix that one lone bug.

Enjoy.

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.
  • I looked around on CPAN for what the state of the art in mixing is...

    The state of the art of mixins in Perl 5 is Class::Trait [cpan.org].

  • So you want to mixin your bomb class and your girlfriend class to your current class:

    package Bomb;

    sub fuse    { ... }
    sub explode { ... }

    package Girlfriend;

    sub fuse    { ... }
    sub explode { ... }

    What happens when you want the Bomb::fuse method (because you can control the timing) but you also want the Girlfriend::explode method (because it's presumably non-lethal)? Now you have an ordering problem and you can't eliminate it. Of course, you could just use delegation, but that does

  • I do most of my mixing in of methods with Sub::Exporter [cpan.org].

    I end up not often needing the override-and-super feature that I see as being the real benefit of mixin.pm -- but Sub::Exporter::Util::mixin_exporter can do that if I need it.
    --
    rjbs
  • Assuming that your diamondy inheritance heirarchy is somewhat sane, the most common problems that cause a hierarchy to be invalid are re-ordering of dependencies, which is relatively easy to spot and fix. Example: package A; our @ISA = qw/B C/; package B; our @ISA = qw/D E/; package C; our @ISA = qw/E D/; Because A inherits from B+C, and they each inherit D+E in a different order, C3 cannot resolve this. The fix is to use D+E in the same order in both places. Most issues converting legacy hierarchies

    • "Assuming that your diamondy inheritance heirarchy is somewhat sane"

      I think I see the problem.