It is not a faux pas to access my variables globally, it's impossible (well, kind of). Global variables are attached to a namespace and that is how other packages access them. my variables are limited to the scope they are declared in.

Often, I'll establish my database connection that the beginning of a package and allow all subs in that package to use the lexically scoped DBI object. This works well if I have many places that use it.

Global variables tend to be more dangerous if they are shared between packages. This makes the packages interdependant. If you need to change a global in one package, you need to search through all other packages that reference this global variable and update them. This is a Bad Thing.

Of course, this also occurs when you have a my $var at the top of a particular package. If you have a bunch of subs that use it and you need to change the name, this could be problematic, but generally much less of an issue than if you're using a global across different packages.

Terminology alert: my variables declared in a package can only be accessed in that package. They are not globals and can only be accessed in the scope in which they were declared. Try the following (strict deliberately not used):

use Data::Dumper;
$x = 1;
print Dumper( \%:: );
[download]

By examining the output, you'll see that $x is in the main namespace. However, by putting a my in front of $x, it's removed from the namespace.

One thing I am unclear on, though: what mechanism does Perl use to access those variables that are lexically scoped and not in a namespace?

Cheers,
Ovid

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

A file is a 'block', hence, unbracketed my's have file scope.
(That is, if there is more than one package in a file, the variable can be seen from all packages;
  if one package is in more than one file, only code in that one file can see the variable.)

p

Oops.

package foo;
my $x = 3;
package bar;
print $x;
[download]

Cheers,
Ovid

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

As I am fond of saying, knowing what the rule officially is is not as important as knowing why that rule evolved and what the tradeoff is. There is always a tradeoff.

BTW Code Complete has an excellent discussion on global variables.

lexical variables are totally hidden from the world outside their immediately enclosing scope.

If, admirably, you wish to encapsulate your main program's lexical (my) variables from your subroutines, one way to do it is simply to enclose your main program in braces. That removes your subroutine from the scope that contains your lexical variables.

Thus the following program fails with the error "Global symbol '$myString' requires explicit package name.":

use strict;
{my $myString = "hello";
mySub();}
sub mySub{
    print $myString;
}
[download]

--
tune

Strictly speaking, file-scoped lexicals (my variables declared outside of a block) aren't globals. They can be dangerous all the same. They'll work fine. However, in longer programs, they can make things difficult to debug. If I have a couple of subroutines

use strict;
my $id = 24601;

sub foo {
   # .. lotsa code
   print "ID number is", $id, "\n";
   # .. more code
}

sub bar {
   if ($id = 3) { # Oops-- I've accidentally set $id to 3
      # do something subtle
   }
}
[download]

If I pass $id as an argument, though, I'm stating explicitly that the actions and results of foo() are dependent on the value of $id. Also, common idiom will keep me from changing the value of my arguments unless I explicitly document otherwise.

If I use $id absolutely everywhere, and it's getting really irritating passing it around all over the place, at least put it behind some get-set routines. That will limit its scope and enable you to control how it is set, and make access stand out in the program. For example:

BEGIN {
my $id = 24601;

sub get_id {
   return $id;
}

sub set_id {
   my ($new_val) = @_;
   $id = $new_val;
}

}

sub foo {
   # .. lotsa code
   print "ID number is ", get_id(), "\n";
   # .. still more code
}
[download]

Some will say that file-scoped lexicals are less of a problem on smaller programs. I mostly agree, except that small programs have an astonishing ability to become large programs, and their code quality rarely improves on the way.

I find package variables less dangerous than file-scoped lexicals, simply because one is disposed to declare them at the top of the program with use vars(). Better yet, if the "variable" isn't supposed to vary, use use constant instead. If you do use them, document that use in each subroutine that uses it, and declare each file-scoped lexical at the top of the file with a comment saying what it is.

So, in summary, I'd avoid worrying about the "politeness" of it. :) Instead, I'd avoid using file-scoped lexicals because it makes your life easier.

stephen

This is more sugar than functionality, I believe. Using this will make your code more readable.

cheers.