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.
  • 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 conflicts are not always a happy thing, it can create some really thorny issue as well. With any non-trivial Role or MI usage you are always dealing with the waterbed in the end (push something down and it just pops back up in the other side).

        - Stevan