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

 

[1DMF]

no i'm confused still if i have a module that defines a var as my $varname. (which is in the package scope of the module name)

and then use that module in another script and try to refer to it with $package/modulename::varname, my script does not run I don't get an error all i get is "The script failed to return the correct HTTP headers" error.

If i change the declare to OUR $varname then the script runs fine.

similarly if I defined a var as my $varname in the script that would be in the package scope $main::varname, not in the scope of the module, I have found if i want to use cross package vars, either I export them from the module (no different than subs etc...) or i define them as OUR if i don't define them as OUR using stict, with or without the package scope i cannot access the variable.

I have proved this with my SQL module and the DSN var, in the script I explicitly state the package name and varname $Sql:SN , only if i define the $DSN var with OUR in the sql module will the script run.

and what are you saying if you want to use global vars don't use strict - gosh, shock, horror, how dare you blaspheme like that


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

 

[TrojanWarBlade]

Ok 1DMF,
You're driving me nuts here! ;-)
Maybe I'm just useless at explaining things so lets look at some code:

#!/usr/bin/perl -w
use strict;

package tester;

sub test {
  print $main::var, "\n";
}

package main;

$main::var = "Dummy text";

tester::test();

Here we have "$main::var" defined in the "main" package (which is the default if you don't define one).
You can see that within the package "tester", the function "test" can still access the global $var that is defined in the main code.

Does that make sense anymore now?


Trojan.

 

[1DMF]

is this only relevant to the MAIN package ? , i've given you the example using 2 separate packages and it doesn't work.

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

 

[TrojanWarBlade]

No, it's not specific to the main package.

#!/usr/bin/perl -w
use strict;

package tester;

$tester::var = "Dummy text";

package main;

print $tester::var, "\n";

Trojan.

 

[1DMF]

then why does my script not work ? if i change the OUR to MY ? - i try to use it correctly stating the package scope as you show ?

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

 

[TrojanWarBlade]

There is no "my" in my code!
You cannot use the fully qualified name with scoped variables (anything that uses "my"). They are NOT package globals, they are scoped variables.
I have been trying (repeatedly) to demonstrate access to package globals to you.


Trojan.

 

[1DMF]

how do you 'declare' a package global using strict?

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

 

[TrojanWarBlade]

You don't need to.
You just refer to it as I did ("$package::variable").


Trojan.

 

[1DMF]

so with in a package you declare it by using it

so instead of.. my $var = "blah" .. you do ... $package::var = "blah"

so is 'my' actualy defining a lexical who's scope is the script/package it is running in?



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

 

[TrojanWarBlade]

my" is indeed defining a scoped variable and the scope (or life) of that variable is limited to the block that surrounds it (curly brackets).
And yes, you do [blue]$package::var = "blah";[/blue] to access a package global variable.
Try it.
See how it goes.


Trojan.

 

[1DMF]

I though just using a variable was bad practice you should always declare them.

I understand the scope within {} braces.

I just removed the declare of $DSN and the script runs fine, so you actualy don't have to declare a variable before you use it, just explicitly include the package.

I still think i'll use 'OUR' to declare it anyway, it's still good practice to declare every variable.

But I see what you were saying regarding the issue of this post, OUR doesn't have to be use to define a cross package global, you just have to reference it correctly!

So what does OUR actually do, look nice when reading the code at a later date, because the var is clearly declared and if you used 'MY', it wouldn't work ?

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

 

[1DMF]

i told a lie, our web hosting has problems, so the ftp failed and it wasn't running the removed declare version.

But the error was the package name error, as the SQL module usage doesn't explicitly state the package name, but i'm sure if it did , it wouldn't error


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

 

[TrojanWarBlade]

my" is used to declare scoped variables.
We have covered that to death.
"our" is used to declare package globals such that you can refer to them without the package name.
For example, you could refer to "$package::variable" just as "$variable" if you declare it first with "our" (assuming you're running under "use strict").



Trojan.

 

[ishnid]

Personally, I prefer to declare with `our' rather than using the full variable name, with package. The only reason for that is to avoid the problem of typos in variables that is one of the main motivations for using strict in the first place.

 

[TrojanWarBlade]

I agree with Ishnid and would like to add that using a cluster of "our" statements at the top of your code goves other benefits too.
Firstly it gives you a place to add a comment about each one explaining what it's for.
Secondly it shows exactly which package globals are in use.
Generally though I think it's best to avoid them altogether if you don't actually need them. You'll often find that you can create a scope for what you need and therefore use scoped variables instead.


Trojan.

 

[1DMF]

i'm glad we finally agree on something and it proved i did understand the scope of the vars depending on where declared and how, i just didn't realise that using explicit packagename/varname was a way to use a var without actually declaring it, which we have agreed is bad practice so doesn't matter, just a shame audiopro's install of PERL was such that OUR didn't work and he needed a workround which kinda threw me with Trojans reply.

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

 

[TrojanWarBlade]

That's a first!
I don't usually get told that I throw people with my answers!



Trojan.

 

[1DMF]

ok i threw myself, are you happy now

No seriously i did, went curb diving on friday, and surfed the tarmac, cheese grated my hands, knee, face, now I know how you felt trojan - lol

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

 

[TrojanWarBlade]

I think you will heal quicker than I will!
The physio says that my little cut will take a long time to get much better and I may never get some of the nerves back in it.


Trojan.

 

[MikeLacey]

Ouch... that's not good

Mike

I am not inscrutable.

Want great answers to your Tek-Tips questions? Have a look at faq219-2884