Global declaration

[audiopro]

When was the global (our) declaration introduced into perl?
One of my ISP's falls over when declaring as 'our' but is ok with 'my'.

Keith

http://www.studiosoft.co.uk

 

[kordaff]

Looking at the Changes files for 5.005 and 5.6, it looks like it changed in a major way between those two versions.

I believe ATTR and VALUE's were added in 5.8.0 (unique is the only one as of 5.8.7)

Kordaff

 

[KevinADC]

yea, it is fairly new, I tried to find when it was introduced but reading through the changes/history is not too easy to plow through.

 

[kordaff]

This is the bit from man perl56delta:

"our" declarations
                                                                                
       An "our" declaration introduces a value that can be best understood as
       a lexically scoped symbolic alias to a global variable in the package
       that was current where the variable was declared.  This is mostly use-
       ful as an alternative to the "vars" pragma, but also provides the
       opportunity to introduce typing and other attributes for such vari-
       ables.  See "our" in perlfunc.

 

[audiopro]

I have written a fairly lengthy script on my local server with a small number of global vars. When I moved it to the remote server where it is to be used it falles over on a number of things namely, 'use warnings and isuuing 'our'. I guess the answer is to either get the ISP to update the version of PERL or go shopping around.
Out of interest, how were global vars declared before the introduction of the 'our' syntax, without upsetting the 'strict' test?

Keith

http://www.studiosoft.co.uk

 

[Xaqte]

audiopro,
This may help:

http://www.perl.com/pub/a/2002/04/23/mod_perl.html

Has some good info about "Making Variables Global With strict Pragma On"

Let us know your results!

X

 

[audiopro]

Thanks Xaqte.
I have read the article but I'm afraid it went right over my head. What it did however is made me question whether I actually need global vars and I have concluded that they are not needed here.
My only problem is accessing the database handle which is needed in quite a number of places within the script.
I can pass the handle in the sub routine call which, I think, is the correct way to program such things.
Please advise me otherwise if this is not the case.


Keith

http://www.studiosoft.co.uk

 

[KevinADC]

yes, that is a good way to handle your situation Keith.

 

[audiopro]

I was forced to re-write part of my latest script in order for it to run on the remote server. I did this by removing all the 'our' references and a number of other changes mostly syntax, which somehow passed my local 'warnings' test but caused the remote server to fall over. Tracing these problems was made even harder by the fact that 'warnings' does not work on the remote server.

One part of this scoping problem still has me confused.
The script uses 5 seperate MySQL tables to maanipulate data. In order to automate a number of the 'form input' processes, I declare the table names at the start of the script and make references to them throughout the script. I was under the impression that I would have to declare this info globally or re-define the data within each sub routine / function.
I now find that I can access the contents of any of the arrays, declared at the start without any global declarations whereas the file handle of the database has to be passed between all of my sub routines.
Could someone explain what is going on?

Keith

http://www.studiosoft.co.uk

 

[KevinADC]

without seeing your script, it's hard to say, but if you use a "my" variable at the beginning of a script, it is still global :

#!perl
use strict;

my $global = 'foo';
do_this();

sub do_this {
print $global;
}

 

[audiopro]

Is 'our' used to reference a var between 2 subs then?

Keith

http://www.studiosoft.co.uk

 

[KevinADC]

see if this helps expalin it:

http://perldoc.perl.org/functions/our.html

the description of our is:

our: declare and assign a package variable (lexical scoping)

 

[1DMF]

Is 'our' used to reference a var between 2 subs then?

Our makes a variable available to the WHOLE script not just a sub or two (depending on place of declaration), I use OUR as follows...

I have a SQL module which uses a global to hold the File DSN to be used...

################
# Start Module #
################

BEGIN {

	# Invoke Exporter
	use Exporter;

	# Set Variables
	our (@ISA, @EXPORT);
	@ISA = qw(Exporter);

	# Define global vars and subs to be exported
	@EXPORT = qw( &getSQL &insSQL &updSQL &delSQL );

}

########################################################################
########################### GLOBAL SUBROUTINES #########################
########################################################################

########################
#  INIT DSN VARIABLES  #
########################

our $DSN;

Then when ever I want to change it in my script I use

##################
# Use SQL Module #
##################
use Sql;

# Set File DSN to use
$Sql::DSN = "full path/LiveSQL.dsn";

as you can see I have used it stating the package scope, as i do not export it in the module.

If in the module I defined it as 'my' the script would not work.

Hope that makes sense

"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you.

 

[TrojanWarBlade]

You CAN share values between only two functions or subroutines using "my". Take a look at my nice little example here:

#!/usr/bin/perl -w
use strict;
# Script to show two functions sharing one scoped scalar.


set_value(12);
print get_value(), "\n";
set_value(63);
print get_value(), "\n";

# print $value;  # Uncomment this line to see proof that $value is scoped

{
  my $value;

  sub set_value {
    $value = shift;
  }
  sub get_value {
    return $value;
  }
}

Trojan.

 

[1DMF]

but you cannot use variables outside their package scope unless you export them or define them with OUR.

my $varname

Defined straight after the Shebang is a script/package global.

i am right aren't I Trojan, see I do remember the stuff you,ishnid etc taught me

"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you.

 

[TrojanWarBlade]

No, you can use them (although possibly not wisely) if you fully qualify the name with the package.

For example you can use "$main::varname" everywhere, even under "use strict;".


Trojan.

 

[1DMF]

stange i tried it and my script falls over, all i did was change the declare from 'our $DSN' to 'my $DSN' and the script won't run, yet as you see i clearly specify the package scope with $Sql:SN

"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you.

 

[TrojanWarBlade]

If you declare a scalar with "my" you scope it and make it unavailable to anything outside that scope.
Fully qualified scalars are effectively globals (or more accurately globals within a package).


Trojan.

 

[1DMF]

ahh Trojan , read my post - my point was that it is only package scope, my usage is (application) global hence requiring the usage of OUR.

which was answering the question what was the diference between my & our.

No, you can use them (although possibly not wisely) if you fully qualify the name with the package.

For example you can use "$main::varname" everywhere, even under "use strict;".

If you declare a scalar with "my" you scope it and make it unavailable to anything outside that scope.
Fully qualified scalars are effectively globals (or more accurately globals within a package).

these two statements contradict each other don't they ?



"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you.

 

[TrojanWarBlade]

Not really.
Without "use strict" you can access "$packge::fred" by simply referring to it as "$fred" but ONLY inside that package.
You can always access it if you fully qualify the name (with or without use strict) as in "$package::fred".
Scoped variables are like stack based variables. They are NOT available outside the current scope in which they are defined (unless you start looking at closures, but that's another story entirely!).
If you wish to use a global variable inside and outside a package that is initialised in your main code (although this is probably a bad idea) you can simply refer to it EVERYWHERE as "$main::fred" (or "$main::whatever_you_like_as_a_name").

Does that explain things any more clearly?


Trojan.