my 'toolchest' of things be put into a 'normal' module and be imported into the OO module

Your toolchest doesn't necessarily have to be a procedural ("normal") module, it too can be object oriented. diotalevi is only suggesting that the relationship between your toolchest module and your application module doesn't appear to be one where inheritance is appropriate.

Inheritance is for when one thing is another thing, where as delegation is when one thing has another thing. These are commonly refered to as is-a and has-a relationships. This is why inheritance in Perl is done through the @ISA array. Delegation in Perl can be accomplished simply by storing one object as an attribute in another object, and calling the first object's methods as appropriate.

To further reinforce the point, consider describing your situation in these terms. Does it make more sense to say "my application is a toolbox" or "my application has a toolbox"? Compare to a frequent example where inheritance is used: "this cat is a mammal" vs "this cat has a mammal." That should help you decide which is appropriate.

How do I use the "has-a" relationship? Say I have a paw object that is used by many of my objects, like the cat object. I'd use it like $cat->paw->scratch, but how would cat.pm use implement the paw.pm?

Has-a relationship methods are generally not directly usable by callers of the delegating class. calling scratch directly on cat doesn't indicate which paw should scratch. Hence, the delegating class has-a method that uses it parameter(s) to determine which instance of paw should do the scratching.

#! perl -slw
use strict;

package paw;

sub new { my $class = shift; return bless { @_ }, $class; }
sub scratch { 
    my $self = shift;
    print "Scratching with $self->{ which } paw"; 
}

package cat;

sub new {
    my $class = shift;
    my %self = @_;
    $self{ paws } = { 
        map{ 
            $_ => paw->new( which => $_ )
        } 'left front', 'right front', 'left hind', 'right hind'
    };
    return bless \%self, $class;
}

sub scratchesWith{ 
    my( $self, $paw ) = @_;
    $self->{ paws }{$paw}->scratch();
}

sub speaks { 
    my $self = shift;
    print $self->{name}, ' says: ',  $self->{voice}; 
}

1;

package main;

my $cat = cat->new( 
    name => 'Tiddles',
    voice=> 'Meow!',
);

$cat->scratchesWith( 'right front' );
$cat->speaks();

__END__
[ 4:08:26.92] P:\test>405381
Scratching with right front paw
Tiddles says: Meow!
[download]

---

Examine what is said, not who speaks.

"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
"Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon

$cat would have an internal data structure that would store instances of the paw class. Then, cat's paw() method would return a paw object. Not that hard, once you see it in action once or twice.

Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

My problem is that I read the book and nod sagely, but when it comes to sitting at the keyboard it doesn't make that much sense any more!

Such is the curse of OO design guidelines: putting them into practical use.