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

    My tweaked version of it is here:

    http://github.com/melo/scripts/blob/master/bin/x-perl-c3-visualize [github.com]

    The original is here:

    http://cpansearch.perl.org/src/FLORA/Class-C3-0.20/util/visualize_c3.pl [perl.org]

    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* NEXT.pm *c

    • While I agree that Class::C3 is better, I still disagree with multiple inheritance. See my latest write-up about this [perl.org]. 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