[Wellington-pm] 'my' and 'our'

[Jacinta Richardson]

Cliff Pratt wrote:

> So, if the variable ($bar) is not used outside the package, it can be 
> declared with 'my'. If it is defined with 'our' it is available anywhere 
> in the package (or scope) as simply $bar, but outside the package (or 
> scope) it is available as $Foo::bar, then?

This is correct.  You can also export package variables using Exporter (just as
you would other symbols) but since this is a terribly bad idea, most people just
use their fully qualified name.

Sam explained the scoping requirements when using "our".  Most people ignore
these by declaring any package variables at the top of their program, but there
are good reasons to share a package variable with only a few subroutines.

If you want to make a package variable in the main scope you can do that too:

	# main script;

	our $foo;

	# elsewhere
	package Foo;

	print $main::foo;

	# or (shorter, but the same)

	print $::foo;

Really though, this suggests that you should be passing the value in as an
argument to a subroutine or something like that.  Manipulation of package
variables is usually called "action from a distance" and can cause all sorts of
maintainer nightmares.

My personal preference for any package variable is to use them as read-only
outside their declared scope.  So if I were to do the above, then I'd only
*change* $main::foo in the main script, and never in the Foo package.

Likewise with Perl's real globals (the special variables), I always localise my
changes:

	open(my $file, "<", $filename) or die $!;

	my $contents;
	{
		local $/;		# slurp mode on
		$contents = <$file>;
	}

because I'm not game to guarantee that a later part of my script (or a module I
use) won't expect the default values.  The exception to this is changes I make
to %ENV in scripts running with taint mode turned on.


> Since all object variables should be accessed by an accessor method, in 
> an object situation, the use of 'our' should be rare.

It's rare, but certainly not unheard of.  Most modules provide a $VERSION
package variable for example.

	use DBI;
	use CGI;
	use File::Find;
	
	print $DBI::VERSION;
	print $CGI::VERSION;
	print $File::Find::VERSION;

As Sam said, in a typical OO design; object variables and class variables are
usually accessed by methods so the use of "our" in these cases is rare.

> Similarly in an ordinary package, you wouldn't normally expose a package 
> variable unless you had a good reason, probably to configure something 
> basic in the package.

Common uses for package variables are as follows:

	* Provide VERSION information
	* Turn on/off verbose or debug modes
	* Provide access to configuration information

There are other good uses for package variables, but they all tend to be
application specific.  In a typical, well designed module, package variables
(other than $VERSION) probably won't exist.

Of course there are an awful lot of badly designed modules, which use package
variables instead of subroutine arguments and returns; but let's not think about
those.  ;)

all the best,

	J


-- 
   ("`-''-/").___..--''"`-._          |  Jacinta Richardson         |
    `6_ 6  )   `-.  (     ).`-.__.`)  |  Perl Training Australia    |
    (_Y_.)'  ._   )  `._ `. ``-..-'   |      +61 3 9354 6001        |
  _..`--'_..-_/  /--'_.' ,'           | contact at perltraining.com.au |
 (il),-''  (li),'  ((!.-'             |   www.perltraining.com.au   |