Re^2: Best practices

It gives me a long list of errors like these:

Variable "$datalock" is not imported at agent.pl line 277.
Variable "$debug" is not imported at agent.pl line 285.Global symbol "
+$datalock" requires explicit package name at agent.pl line 277.
Global symbol "$debug" requires explicit package name at agent.pl line
+ 285.
[download]

I tried do and require. I had to copy use commands from the main part to the second one to get it compiled this far but now it whines about many variables like:

our $datalock = MyLock::new;
our $debug = 1; #Debug messages
[download]

I understand that do works in limited lexical view but how should I originally declare variables which spans to global scope if "our" is not global enough?

Comment on Re^2: Best practices - if any? Select or Download Code

Replies are listed 'Best First'.
Re^3: Best practices - if any? by almut (Canon) on Feb 20, 2010 at 23:22 UTC
how should I originally declare variables which spans to global scope if "our" is not global enough? our is lexically scoped, and files included via `require` and friends have their own implicit lexical scope (so you'd need to redeclare your `our` variables). You might also declare your global package variables using `use vars` in order to share them across files with strictures enabled. As another alternative, just fully qualify every occurrence of a global variable — as long as they're in the main namespace, that would simply be something like `$::foo`. The advantage of the latter approach is that they're immediately evident, and that the required additional typing helps to keep them at a minimum :) That said, think twice before you do so! What is the real idea behind splitting the code? You say "putting couple of big subs to a safe place", but why are they unsafe in their original place? If modularisation/reuse is the idea, why not create proper modules? Also, having to share many variables across different files typically is an indication of bad design in the first place...	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^3: Best practices - if any?
by almut (Canon) on Feb 20, 2010 at 23:22 UTC

how should I originally declare variables which spans to global scope if "our" is not global enough?

our is lexically scoped, and files included via require and friends have their own implicit lexical scope (so you'd need to redeclare your our variables).

You might also declare your global package variables using use vars in order to share them across files with strictures enabled. As another alternative, just fully qualify every occurrence of a global variable — as long as they're in the main namespace, that would simply be something like $::foo. The advantage of the latter approach is that they're immediately evident, and that the required additional typing helps to keep them at a minimum :)

That said, think twice before you do so! What is the real idea behind splitting the code? You say "putting couple of big subs to a safe place", but why are they unsafe in their original place? If modularisation/reuse is the idea, why not create proper modules? Also, having to share many variables across different files typically is an indication of bad design in the first place...

[reply]
[d/l]
[select]