Re: Note on usage of ours variables and a question

in reply to Note on usage of ours variables and a question

Here is a replacement for your module and script showing one way of achieving this.

use strict;
use warnings;

package Example;

use parent 'Exporter';
our ($VERSION, @EXPORT, $debug);
$VERSION    = '1.0';
@EXPORT     = qw($debug);
$debug      = 1;

1;
[download]

#!/usr/bin/env perl 
use strict;
use warnings;

use lib '.';
use Example;

print "debug = $debug\n";
[download]

I've removed a lot of your boilerplate for clarity. I've also adhered to convention and capitalised the module name. Note that filling @EXPORT is generally frowned upon. Much better to use @EXPORT_OK and allow the script to decide which symbols to import.

BTW does Perl have a system variable "debug" that is global and does not need qualification with the package name?

No, but it does have the warnings pragma and $^W which you might consider similar. I'd stick with your own flags unless you have a good reason to do otherwise, though.

Comment on Re: Note on usage of ours variables and a question Select or Download Code

Replies are listed 'Best First'.
Re^2: Note on usage of ours variables and a question by afoken (Chancellor) on Nov 20, 2019 at 20:39 UTC
`use parent 'Exporter';` No need to inherit from Exporter, importing its `import()` method is possible since Perl 5.8.3 (2004-01-14), and it is almost always sufficient: `use Exporter qw( import );` [download] See also Re: Advice on style, Re^2: Advice on style, and of course Exporting-Without-Inheriting-from-Exporter of Exporter. Alexander -- Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)	[reply] [d/l] [select]
Re^2: Note on usage of ours variables and a question by likbez (Sexton) on Nov 20, 2019 at 02:46 UTC
> Note that filling @EXPORT is generally frowned upon. Much better to use @EXPORT_OK and allow the script to decide which symbols to import. I agree, but the road to hell is paved with good intentions. It depends whether modules in question are written as reusable or not. My are not. Intentionally. One advantage of using export is that there can't be mismatch between your intentions and actually exported variables. Which you will discover several months down the road. Been there, done that. Also for some idiosyncratic reasons I consider this quest for reusability as often misguided obsession, which cost you a lot of man hours with zero return. Even slight adaptation of module to the task in hand cuts the code lines in half in comparison with using a "universal/reusable" version. Number of errors in your code is generally proportional to the number of codeines. And life is short. It is something similar with polishing your OO classes instead of doing productive work. Or converting your perfectly valid procedural version into the OO version, because everybody are using OO.	[reply]

In Section Seekers of Perl Wisdom