http://www.perlmonks.org?node_id=932557


in reply to Re: Perl Modules with 2 or more classes
in thread Perl Modules with 2 or more classes

This is actually something I've always found frustrating about OOP. To be fair, it's not like any other language really has any better solution, and Python's answer seems to be even worse, while pretending to be better somehow.

I'm a big fan of compilation-on-demand. So I want my callers to 'use' as little as possible. That means 'use'ing very specific subclasses. That means they must exist in unique files.

Unique files are good for maintainability, contrary to Python credo. Files/classes that have old, old mtimes are by definition "stable". It can be trivially proven that they have not changed. Additionally, multiple files helps avoid merge conflicts for parallel team development. Split the responsibility of the developers on the team, and split the responsibility of the classes/files they are working on accordingly. Good design scales maintainability as well.

OTOH, I'm also a big fan of ease-of-use. Why do I have to 'use DBD::blah'? I don't call anything in there... DBI does. Why doesn't DBI 'use' it for me instead? Having one core module to rule all the others is a good thing. But then you don't really know for sure what's getting brought in and when... so debugging is more complicated.

I digress... just things worth thinking about...

--Dave

Replies are listed 'Best First'.
Re^3: Perl Modules with 2 or more classes
by Anonymous Monk on Oct 20, 2011 at 22:20 UTC
    Why do I have to 'use DBD::blah'? I don't call anything in there... DBI does. Why doesn't DBI 'use' it for me instead?

    Huh? You don't need to use DBD::blah, just do DBI->connect('dbi:blah:FooBarDB') and it will do what you're asking for. You basically only need to use DBD modules to import extra things they might provide, like use DBD::Oracle qw/:ora_types/; for Oracle-specific data types.

    Maybe you were asking rhetorically to make a point?