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)

Friday January 30, 2009
11:04 AM

Graphing the hierarchy (you won't believe this)

[ #38369 ]

After sorting the bug in my Class::Sniff post, I had 33 classes to juggle (and this for a database table with effectively only 6 fields to store!). So I decided to turn the output into a png. I can't have them here, so you can view the horror on my LiveJournal.

Feel free to comment either here or there.

Oh, and if you're wondering how I made that nifty graph, remember how I said that using a tree is a huge gain for code simplicity? Yup. Transform it into a graph and print:

my $dump  = Class::Sniff->new($root);
my $graph = Graph::Easy->new;
for my $node ($dump->tree->traverse) {
    my $class = $node->value;
    next if $class eq $root;
    $graph->add_edge_once($node->parent->value, $class);

my $graphviz = $graph->as_graphviz;
open my $DOT, '|dot -Tpng -o clip.png' or die "Cannot open pipe to dot: $!";
print $DOT $graphviz;
close $DOT;

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.
  • There is a script in the Class::C3 distribution that does this and much more.

    My tweaked version of it is here: []

    The original is here: []

    Best regards,

    life is short
    • Sorry, I don't think I was clear about my intent. There are a number of alternatives for doing this, but the name of this project, Class::Sniff, suggests my purpose: searching out code smells in OO code. To this end, merely collecting the hierarchy is the first bit. I also have to look for inappropriate inheritance, multiple inheritance, which methods are overridden where, etc. As a result, I'll eventually need to collect a lot more state about everything and provide analysis tools.

  • Well, I agree, that inheritance tree does look nasty. However all that MI in DBIC is managed with Class::C3 which checks the sanity of your MI at compile time using the C3 method resolution. Basically mst wanted roles before there was a stable implementation of them so he used MI instead. Being insane but not stupid Matt decided to use Class::C3 to manage his MI. So while it may look really ugly and nasty, it is pretty well through out and not nearly as fragile as traditional Perl MI is (*cough* *c

    • While I agree that Class::C3 is better, I still disagree with multiple inheritance. See my latest write-up about this []. I should also note that Matt's done fantastic work with DBIx::Class and this is not directed at him specifically. He's a careful programmer and I appreciate that. That still doesn't avoid that fact that MI is a minefield.

  • I think you are misinterpreting your diagram. When I see all those modules, I think: "Aha, look at all those subtle complexities I don't have to understand." If DBIC wasn't there, you'd be doing that all yourself.

    Unicode is complicated. SQL databases are extremely complicated. Object/relational mapping is complicated. DBIC takes on complexity to hide it from the rest of your app.

    Think about what a mess your app would be if you had a home-grown ORM -- you'd have all these complexities, but you'd have to

    • I'm quite happy with my job and my work app. It's great. There are just frustrating corners from time to time :)

      And with roles, the complexity wouldn't be the same because roles at least provide some compile-time sanity about method conflicts and requirements, something which MI cannot do.

      • And with roles, the complexity wouldn't be the same because roles at least provide some compile-time sanity about method conflicts and requirements, something which MI cannot do.

        Actually C3 does detect some particularly horrid ambiguities that can crop up in MI and via the next::method package it is possible to have a consistent traversal path through your MI hierarchy that is assured to stay consistent no matter what angle you look at it from.

        Also, experience has taught me that role requirements and