«

Hello,

I have the following problem. I had a script that contained only one
global variable which was called $DEBUG. I just used it to print out
various think or do some checks in debugging mode

print "number of objects $n_obj\n" if $DEBUG ;
check_sanity if $DEBUG ;

The program grew and now I splitted it up into several modules.

Question: what to do with the debug variable?

* I could make it local to all of the functions, but I would really hate
passing it through to each of the functions separately. Firstly, IMO this
is one of the few cases where global variables are justified, and second,
this would require me to make hundreds of modifications in the code.

* I could make it a global variable in each of the modules, and create a
function that switches on the debugging for one module only. This would
have the advantage that I could specify which module to debug.
Disadvantage is that I need to remember to switch it on in every module
if I want to switch it on globally.

* Finally, I could make a separate module with generic tests for sanity and
printing warning messages, and that module would hold the only instance
of the $DEBUG variable. Again, many modifications in the code required.

Of course, I can imagine that there are gazillions of other ways of doing
that, and that there are specific modules that do precisely what I want.
What route would you recommend?

Regards,

January

January Weiner wrote:
> I have the following problem. I had a script that contained only one
> global variable which was called $DEBUG. I just used it to print out
> various think or do some checks in debugging mode
>
> print "number of objects $n_obj\n" if $DEBUG ;
> check_sanity if $DEBUG ;
>
> The program grew and now I splitted it up into several modules.
>
> Question: what to do with the debug variable?
>
> * I could make it local to all of the functions, but I would really hate
> passing it through to each of the functions separately. Firstly, IMO this
> is one of the few cases where global variables are justified, and second,
> this would require me to make hundreds of modifications in the code.
>
> * I could make it a global variable in each of the modules, and create a
> function that switches on the debugging for one module only. This would
> have the advantage that I could specify which module to debug.
> Disadvantage is that I need to remember to switch it on in every module
> if I want to switch it on globally.
>
> * Finally, I could make a separate module with generic tests for sanity and
> printing warning messages, and that module would hold the only instance
> of the $DEBUG variable. Again, many modifications in the code required.

You didn't mention the simplest way:

Keep it a global variable in one of the modules and use its fully
qualified name when calling it from other modules, e.g. $MyModule:EBUG

--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl

Gunnar Hjalmarsson <> wrote:
> > * Finally, I could make a separate module with generic tests for sanity and
> > printing warning messages, and that module would hold the only instance
> > of the $DEBUG variable. Again, many modifications in the code required.

> You didn't mention the simplest way:

> Keep it a global variable in one of the modules and use its fully
> qualified name when calling it from other modules, e.g. $MyModule:EBUG

This is more or less my third way. It requires modifying each of the
statements containing $DEBUG and including the module in all the other
modules and the main code. But yes, I am considering this, thanks!

j.

Abigail <> wrote:
> You seem to have the impression that if you're using a variable
> $MyModule:EBUG, you have to have a MyModule.pm, and you have
> to 'use' that file.

> That's not true.


> package Fnurd;

> use strict;
> use warnings;

> say "Hi, I'm a debugging message." if $MyModule:EBUG;

Ah, OK. I always used only functions exported from modules or OO modules.
These must be exported and the modules must be imported. I assumed that the
same holds for the variables.

j.

Abigail <> wrote:
> That's what I usually do, except that put the variable in main, so I
> can just use $:EBUG.

This is it! Thank you (both) very much.

> srand 123456;$-=rand$_--=>@[[$-,$_]=@[[$_,$-]for(reverse+1..(@[=split
> //=>"IGrACVGQ\x02GJCWVhP\x02PL\x02jNMP"));print+(map {$_^q^"^}@[),"\n"

'eresal nPhkuHrJ cteatro'? There is something disconcerting in this
message...

j.

Abigail schrieb:
>
> You seem to have the impression that if you're using a variable
> $MyModule:EBUG, you have to have a MyModule.pm, and you have
> to 'use' that file.
>
> That's not true.
>
>
> package Fnurd;
>
> use strict;
> use warnings;
>
> say "Hi, I'm a debugging message." if $MyModule:EBUG;
>
>
> works well.
>
>
> Abigail

For curious lurkers like me, soaking up wisdom from c.l.p.m, I think it
should be mentioned that $MyModule:EBUG needs to be declared via 'our'
for this to work, because:

$ perl -Mstrict -Mwarnings -le'
package MyModule;
my $DEBUG = 1;
package Fnurd;
print "Debug on" if $MyModule:EBUG;
'
Name "MyModule:EBUG" used only once: possible typo at -e line 5.

whereas with 'our':

$ perl -Mstrict -Mwarnings -le'
package MyModule;
our $DEBUG = 1;
package Fnurd;
print "Debug on" if $MyModule:EBUG;
'
Debug on


But then I don't even have to use the fully qualified name:

$ perl -Mstrict -Mwarnings -le'
package MyModule;
our $DEBUG = 1;
package Fnurd;
print "Debug on" if $DEBUG;
'
Debug on


Toying a little more, I find that

$ perl -Mstrict -Mwarnings -le'
package MyModule;
my $DEBUG = 1;
package Fnurd;
print "Debug on" if $DEBUG;
'
Debug on

works equally well.

What am I not understanding?

Thank you,
Andreas Pürzer

--
Have Fun,
and if you can't have fun,
have someone else's fun.
The Beautiful South

Andreas Pürzer wrote:
> Abigail schrieb:
>> January Weiner wrote:
>>> Gunnar Hjalmarsson <> wrote:
>>>> Keep it a global variable in one of the modules and use its fully
>>>> qualified name when calling it from other modules, e.g. $MyModule:EBUG
>>>
>>> This is more or less my third way. It requires modifying each of the
>>> statements containing $DEBUG and including the module in all the other
>>> modules and the main code. But yes, I am considering this, thanks!
>>
>> You seem to have the impression that if you're using a variable
>> $MyModule:EBUG, you have to have a MyModule.pm, and you have
>> to 'use' that file.
>>
>> That's not true.
>>
>> package Fnurd;
>>
>> use strict;
>> use warnings;
>>
>> say "Hi, I'm a debugging message." if $MyModule:EBUG;
>>
>> works well.
>
> For curious lurkers like me, soaking up wisdom from c.l.p.m, I think it
> should be mentioned that $MyModule:EBUG needs to be declared via 'our'
> for this to work, because:
>
> $ perl -Mstrict -Mwarnings -le'
> package MyModule;
> my $DEBUG = 1;
> package Fnurd;
> print "Debug on" if $MyModule:EBUG;
> '
> Name "MyModule:EBUG" used only once: possible typo at -e line 5.

That's because the my() declared $DEBUG and $MyModule:EBUG are two
different variables...

> whereas with 'our':
>
> $ perl -Mstrict -Mwarnings -le'
> package MyModule;
> our $DEBUG = 1;
> package Fnurd;
> print "Debug on" if $MyModule:EBUG;
> '
> Debug on
>
> But then I don't even have to use the fully qualified name:
>
> $ perl -Mstrict -Mwarnings -le'
> package MyModule;
> our $DEBUG = 1;
> package Fnurd;
> print "Debug on" if $DEBUG;
> '
> Debug on

You do have to use the fully qualified name if you call the variable
from somewhere outside the MyModule package.

> Toying a little more, I find that
>
> $ perl -Mstrict -Mwarnings -le'
> package MyModule;
> my $DEBUG = 1;
> package Fnurd;
> print "Debug on" if $DEBUG;
> '
> Debug on
>
> works equally well.

Not if you call it from some other module or from the main script.

> What am I not understanding?

Maybe you didn't read the whole thread carefully enough?

--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl

Quoth Gunnar Hjalmarsson <>:
> Andreas Pürzer wrote:
>
> > whereas with 'our':
> >
> > $ perl -Mstrict -Mwarnings -le'
> > package MyModule;
> > our $DEBUG = 1;
> > package Fnurd;
> > print "Debug on" if $MyModule:EBUG;
> > '
> > Debug on
> >
> > But then I don't even have to use the fully qualified name:
> >
> > $ perl -Mstrict -Mwarnings -le'
> > package MyModule;
> > our $DEBUG = 1;
> > package Fnurd;
> > print "Debug on" if $DEBUG;
> > '
> > Debug on
>
> You do have to use the fully qualified name if you call the variable
> from somewhere outside the MyModule package.

No, not if you use 'our'. An often-overlooked property of 'our' is that
it creates a lexical alias to the package variable: in simple terms, you
can use that variable unqualified for the rest of the lexical scope,
even if you change package. This is why the second example above works
as it does.

> > Toying a little more, I find that
> >
> > $ perl -Mstrict -Mwarnings -le'
> > package MyModule;
> > my $DEBUG = 1;
> > package Fnurd;
> > print "Debug on" if $DEBUG;
> > '
> > Debug on
> >
> > works equally well.
>
> Not if you call it from some other module or from the main script.

More precisely: if you attempt to use it in some other lexical scope.
Package statements are irrelevant for lexicals, so if you have some code
in another file that is in package MyModule it still can't see the
lexical.

Ben

Quoth :
> _
> Gunnar Hjalmarsson () wrote on VCCLXXVI September
> MCMXCIII in <URL:news:>:
> -: January Weiner wrote:
> -: > I have the following problem. I had a script that contained only one
> -: > global variable which was called $DEBUG. I just used it to print out
> -: > various think or do some checks in debugging mode
<snip>
> -:
> -: You didn't mention the simplest way:
> -:
> -: Keep it a global variable in one of the modules and use its fully
> -: qualified name when calling it from other modules, e.g. $MyModule:EBUG
>
> That's what I usually do, except that put the variable in main, so I
> can just use $:EBUG.

If this code might be used in some other, unrelated program (that is,
the debugging state belongs with the module, not the program as a whole)
you can create a package global and then import it into your other
packages:

package MyModule;

require 'Exporter';
our @ISA = 'Exporter';
our @EXPORT_OK = qw/$DEBUG/;

our $DEBUG;

__DATA__

package MyModule::Foo;

use MyModule qw/$DEBUG/;

# now just use $DEBUG, as before

__DATA__

Ben

January Weiner wrote:
> Hello,
>
> I have the following problem. I had a script that contained only one
> global variable which was called $DEBUG. I just used it to print out
> various think or do some checks in debugging mode
>
> print "number of objects $n_obj\n" if $DEBUG ;
> check_sanity if $DEBUG ;
>

This post is orthogonal to the other messages in this thread, but you
may want to check out

Carp::Assert
Log::Log4perl

Mark