Mano_Man has asked for the wisdom of the Perl Monks concerning the following question:

Hi Monks,

I'm looking for a way to have identical global variables in every package, and a single module that utilizes the data from them

Example:

package my_first; use Debug; # Imports in sub debug our $DEBUG_FLAG =1; debug("Print me"); #prints: Print me 1; package my_second; use Debug; our $DEBUG_FLAG =0; debug("Print me"); #prints none 1; package Debug; our $DEBUG_FLAG =0; #Default value sub debug($) { if(DEBUG_FLAG){ say $_[0]; } } 1;

Hope this is clear, appreciate any help.Looking for smart suggestions, better ways to do this (not OOP wise), and any other tidbit you can think of.

Replies are listed 'Best First'.
Re: How to log to different outputs from different packages
by 1nickt (Canon) on Nov 19, 2017 at 14:33 UTC
      Thanks 1nickt, looking into it.
Re: Overriding Global Variables
by haukex (Archbishop) on Nov 19, 2017 at 13:55 UTC

    There are several ways to do this, and which ones are best depends a bit on what you're trying to do - normally, a "debug" flag is a global thing, enabled only once by a command line option or environment variable. I'm not sure why you need multiple packages to access it - will the flag be switched on and off during the run of your program? If so, a different design is probably better, because otherwise you may run into issues with the dynamic scope of the setting. To implement only what you've asked so far, I'd suggest to just have a single variable and access it in the Debug package via $Debug::.

    use warnings; use strict; { package Debug; use Exporter 'import'; our @EXPORT = qw/debug/; our $FLAG = 0; # package variable sub debug { if ($FLAG) { print @_; } } } { package Foo; Debug->import; # normally "use Debug;" $Debug::FLAG = 1; # global enable debug("Hello\n"); # prints "Hello" } { package Bar; Debug->import; # normally "use Debug;" $Debug::FLAG = 0; # global disable debug("World!\n"); # doesn't print }

      Hi haukex,

      The idea was that the "debug" function is enabled or disabled in accordance to the module that uses it, effectively enabling a clean and easy way to debug different modules as part of a very large flow, involving many. One "debug" variable doesn't suit this purpose, and also adds in the clutter of setting and resetting the variable whenever needed.

        > clutter of setting and resetting the variable whenever needed.

        That's where you use local to change the flag.

        The old value will be reset automatically after the dynamic (runtime) scope is left.

        edit

        FWIW you could additionally have a lexical variable with my which is block scoped and check it using PadWalker

        You need to decide which flag takes precedence though, I'd say my over our

        Cheers Rolf
        (addicted to the Perl Programming Language and ☆☆☆☆ :)
        Je suis Charlie!

        the "debug" function is enabled or disabled in accordance to the module that uses it

        I see, in that case I would concur with karlgoethebier and I think an OO approach is probably best - each module can get an object with an individual debug flag. And looking into existing logging modules, as 1nickt said, makes sense before you re-invent that wheel.

Re: Overriding Global Variables
by LanX (Saint) on Nov 19, 2017 at 13:53 UTC
    This

      our DEBUG_FLAG =1;

    belongs to the importing package, so you need to know its name

    TIMTOWTDI

    • simplest way is to use caller inside debug() to get it.
    • I would personally try to export a different debug() from every import() having a reference to your $DEBUG_FLAG inside the closure.

    Sorry, no code now, I'm on mobile at the moment and can't test.

    NB: DEBUG_FLAG has no sigil in your example! Please post only valid code!

    Cheers Rolf
    (addicted to the Perl Programming Language and ☆☆☆☆ :)
    Je suis Charlie!

      Can the caller package and its global variables be accessed without it being known to the "Debug" module via 'use' or 'require? I'd love to see an example if you get around to it. Thanks LanX.
        Here a simple demonstration without importing ( ::debug is short for main::debug )

        use strict; use warnings; use Carp; package main; sub debug { my ($pkg) = caller; { no strict 'refs'; return unless ${ "${pkg}::DEBUG_FLAG" }; } carp "@_"; } package My_First; our $DEBUG_FLAG = 1; ::debug( "Print " . __PACKAGE__ ); # prints package My_Second; our $DEBUG_FLAG = 0; ::debug( "Print " . __PACKAGE__ ); # doesn't print

        Print My_First at d:/Users/RolfLangsdorf/pm/pm_debug_caller.pl line 23 +.

        Cheers Rolf
        (addicted to the Perl Programming Language and ☆☆☆☆ :)
        Je suis Charlie!

        Update

        improved code with Carp to report file and line from callers perspective.

Re: Overriding Global Variables
by karlgoethebier (Abbot) on Nov 19, 2017 at 16:23 UTC
    "...not OOP wise..."

    But why? Don't your requirements cry for this approach? Just a question before i fire up my modest ideas.

    Best regards, Karl

    «The Crux of the Biscuit is the Apostrophe»

    perl -MCrypt::CBC -E 'say Crypt::CBC->new(-key=>'kgb',-cipher=>"Blowfish")->decrypt_hex($ENV{KARL});'Help

      I take back my "OOP" statement. I agree that it calls for that ;-).
        "...I take back..."

        Some callow ideas. Perhaps they are helpful:

        Best regards, Karl

        «The Crux of the Biscuit is the Apostrophe»

        perl -MCrypt::CBC -E 'say Crypt::CBC->new(-key=>'kgb',-cipher=>"Blowfish")->decrypt_hex($ENV{KARL});'Help

Re: Overriding Global Variables
by Anonymous Monk on Nov 20, 2017 at 13:39 UTC
    In a very similar situation (different language ...) we had many hundreds of modules and different types of messages. We simply defined a common set of module-id and message-type constants, and a debugging routine, in a common module shared by all. Each module contained a pair of constant-declarations with consistent names, made equal to one of these constants, and passed them to all debug-message calls. A console command then allowed the user to turn on/off any of these messages during the run, by module-name and/or by message-type. Q.E.D.