Though not a recommended practice (in theory), one could put both OO and non-OO codes in a package. In that case, you would use Exporter for the non-OO code. Take the following as an example

There are a _DB.pm...

# Constructor
# Usage: $MyDB = DB::MyDB->dbconnect("db", "username", "pwd")
sub dbconnect { 
    # stuff 
}

# Usage: $tbl = $MyDB->selectall_tbl($select_statement)
#     where $tbl is a 2D array
sub selectall_tbl {
    # stuff
}

1 ;
[download]

.. and a MyDB.pm...

package DB::MyDB ;
require Exporter ;
@ISA = qw(Exporter) ;
@EXPORT = qw(print_tbl) ;
use DBI ;
use strict ;

use DB::_DB ;    # OO stuff

# Usage: print_tbl($tbl)
#     where $tbl = $MyDB->selectall_tbl($select_statement)
#     return nice text result
sub print_tbl {
    # stuff
}

1 ;
[download]

... and a MyWebDB.pm

package DB::MyWebDB ;
use Apache::Reload ;
use strict ;

use DB::_DB ;    # OO stuff

1 ;
[download]

_DB.pm contains all the OO stuff for DB access--which basically forms a base object. But there are an Apache environment and a regular environment, where you might need additional methods/subroutines specific for them respectively. Well, you could write some child objects, which inherit the base object from _DB.pm, with additional methods.

Or, more lazily, you could just write some subroutines and export them. Since subroutines (or closure, for that matter) are theoretically less CPU- and memory-expensive than objects and methods, and in Perl, less code to write, it might not be all that unreasonable a thing to do in Perl--which, as a good thing, doesn't force you to program one way or the other. Just as in Java when you need to write an utility class, which contains no data and nothing but class methods, in Perl you just write a "package."

In other words, the question one might ask is: are these really methods, or could these just be subroutines or closure?

(O, yah, you could merge MyDB.pm and MyWebDB.pm together by dynamically determining where you are, as suggested in a previous reply, in case you want to get cute.)