The closest thing to what you describe would be to make "PrintToScreen" a singleton object. Your new method would be something like:

my $instance;
sub new
{
   my ($class, $loglevel) = @_;
   $instance ||= do {
      print "$class $VERSION started with loglevel $loglevel\n"
         if $loglevel >= 3;
      bless { _usersetloglevel => $loglevel }, $class;
   };
}
[download]

That way, when your code calls PrintToScreen->new it will always return the same object, at the same loglevel.

Now, it needs to be said that singletons are generally considered code smell - i.e. a sign of poorly thought out code. There are valid use cases for them, but not many. Using a singletons for logging will come back to bite you when you decide you'd like for part of your code (perhaps the network interaction but, say) to be logged in great detail, but not the rest of your code. (Perhaps because you're trying to figure out a bug in the networking stuff without being distracted by hundreds of irrelevant messages from parts of the system you know are working well.)

Better for your logger to be a normal class so you can do:

my $network_connection = NetworkConnection->new;
$network_connection->set_logger( PrintToScreen->new(3) );

my $database_connection = DatabaseConnection->new;
$database_connection->set_logger( PrintToScreen->new(1) );
[download]

See also: Stack Exchange: Why is Global State so Evil?

PS: not sure why you're using "recursively" in your message title. Recursion in computer science is when a function (directly or not) calls itself. A quick example of recursion to implement integer multiplication using just addition and subtraction:

use strict;
use warnings;

sub multiply_integers
{
    die "two positive integers!\n"
        if @_ != 2
        || grep { not /^[1-9][0-9]*$/ } @_;
    
    my ($x, $y) = @_;
    return $x if $y == 1;
    return $x + multiply_integers($x, $y-1);
}

print multiply_integers(7, 6), "\n";
[download]

Thanks for the fast reply. For the 'recursive-thing': Yes, you're right. What I meant was what I think you call cascade: So if a module uses a module and that module uses a module again...
But then I think you're right that it just comes down to a Global State.
And trust me, In this case, I would also already be happy with that! :-)
I'm gonna check if I'll get you're suggested code to work.
Thanks again!
The great mistake is to anticipate the outcome of the engagement; Let nature take it's course, and your tools will strike at the right moment.

If I understand you correctly, tobyink's reply fits pretty well. One more thing to note, however, is that there already exists a plethora of Perl logging modules, many of which will probably do what you want.

If you're mainly doing this as a learning exercise, however, then, again, tobyink left you some valuable advice.

Thank you too!
I will definitely take a look at plethora logging modules! My main goal now is to understand tobyinks post, but just for this situation, these modules might could help me out too.
The great mistake is to anticipate the outcome of the engagement; Let nature take it's course, and your tools will strike at the right moment.

Wouldn't another approach be to pass the logger object to the module if you wish it to use that logger object instance?

something like:

# calling program stuff
my $loggerHandle = new myLogger();
my $workerHandle = new myWorker();

my $returnValue = $workerHandle($loggerHandle, $Parameter, $Option, $E
+tc);
[download]

You achieve the intended result, which is a lot like Global State, but not with a Global State implementation. You tell the subordinate method which logger to use, and its logging behavior is driven by its previously-established logging level attribute.

Or am I out in left field here, and worse, the game is soccer?

Precisely. You should give functions and objects everything they'll need to perform their duties. Loggers, database handles, etc should be provided to objects as part of their constructor, or passed to each method/function call.

The name for this general style of programming is "dependency injection" - you inject into an object/function everything it depends on. Generally speaking it is considered a good thing to do.

That said, it is possible to go far with dependency injection. If a function needs to fetch something from the web, it's a good idea to allow people to "inject" an LWP::UserAgent or compatible object. But if a function needs to multiply two numbers together, then allowing people to inject their own implementation of integer multiplication as a coderef is a step too far. Generally common sense will tell you what dependencies should be injectable and what can be hard-coded.

perl -E'sub Monkey::do{say$_,for@_,do{($monkey=[caller(0)]->[3])=~s{::}{ }and$monkey}}"Monkey say"->Monkey::do'