Perl keywords for declaring variables: my, our and local???

[jira0004]

Hi,

I do a substantial amount of development work in Perl.

Typically, I use the Perl strict module to force the declaration of variables via the use of the Perl keword my . Presently, I am involved in an integration project at work. We are using Perl to integrate several technologies. I have successfully encouraged my development team to use the Perl strict module to force declaration of variables to avoid the various pitfalls associated with the ability to use variables without declaring them, such as misspelling a variable name and having Perl treat it as two different variables instead of two instances of the same variable. One of the members of my team is using the Perl keyword our to declare variables within one of the Perl scripts we are developing. I have never seen the Perl keyword our and so didn't know it could be used to declare variables within a script.

What is the Perl keyword our? What is it used for? How is declaring a variable using the keyword our different from declaring a variable using my?

Thanks for any helpful replies and input

Sincerely,

Peter Jirak

[e-mail]

[cchampion]

You can learn what you need in Ovid's excellent tutorial 'our' is not 'my'

Also check cLive ;-)'s tutorial The difference between my and local

[Anonymous Monk]

what the fuck ANS.....!?

[Anonymous Monk]

agree!!!

[krusty]

our is a lexically scoped alias for a global variable. Will create the global if it didn't exist already.

See the following code:

#!/usr/bin/perl

our $a = "foo";

print "$a\n";


package Our;

print "$Our::a  <--shouldn't print anything here\n";
print "$main::a <--should print 'a' from the main symbol table here\n"
+;
print "$a       <--should also print 'a' from the main symbol table he
+re\n\t\tdue to lexically scoped alias\n";

Results are:

foo
        <--shouldn't print anything here
foo     <--should print 'a' from the main symbol table here
foo     <--should also print 'a' from the main symbol table here
                due to lexically scoped alias

By default any global variables you create automatically populate the "main" symbol table, %main::. With a package declaration you could change which symbol table you are populating when you declare unqualified variables.

But our is a lexical decalaration. In the case above the declaration was file scoped. That's why I still got something back when I gave it an unqualified print statement print "$a\n" after the package declaration.

Don't forget just because it's a lexically scoped variable, it's still an alias for a global variable. Hence when I reassigned $a = "foo" with the our declaration, I blew away the old value.

Any comments are welcome.
Cheers,
Kristina

[demerphq]

our is a lexically scoped alias for a global variable. Will create the global if it didn't exist already

This is a little misleading. Global variables are created on first use regardless. And when you say alias I can see what you mean but wouldnt use that term personally. strict complains if it sees a symbol that isn't a fully qualified package variable (aka global) or if it hasn't been declared by my or it doesnt meet a handful of esoteric exceptions (like $_ and $a $b). our is the workaround to tell strict that in a given lexical scope a given symbol defaults to meaning the package variable and not to worry if it hasnt been declared already as a lexical. It means you don't have to fully qualify your globals, which also means that strict can catch your typos. An alternate means to accomplish this goal is to use vars qw(); which I personally prefer.

By default any global variables you create automatically populate the "main" symbol table, %main::. With a package declaration you could change which symbol table you are populating when you declare unqualified variables.

Again this is correct but IMO a little muddled. Unqualified globals (with certain exceptians left aside) are presumed to refer to the package in which they are used. If no package declaration is provided then it defaults to 'main'. To fully qualify something to main you need not write $main::foo but rather $::foo. But again declaration does not directly mean creation or population. It does indirectly as it potentially means "first use" but its the "first use" rule that creates the var and not the declaration. Ie:

package Foo;
use strict;

use vars qw/$DEBUG/;

our $DEBUG;

$Foo::DEBUG=1;

neither "declaration" is necessary in this case at all.

Personally I like to think of it this way: "our and use vars advise strict not to complain about unqualified globals.", "my declares a new lexical variable" and "local creates a new dynamic scope for a variable"


---
demerphq

[merlyn]

Column #46 of my UR series is about that very subject, although I don't have it up on my website because it has to be published in the magazine first. Check back in a few weeks.

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

[jira0004]

I want to thank you and several others who responded to my query soo quickly. Thansk for the help!

I have another question. The our keyword is not in Programming Perl, 2nd edition by Larry Wall, Tom Christiansen and you, Randal L. Schwarts. If we are going to use the our keyword construct in the script we are developing at work to deliver to our customers, then I need to know the first version of Perl in which our was introduced and supported. That way I can know whether a customer who has a given version of Perl will be able to run the script we are developing. If our is too new and only in very recent versions of Perl, then I will just ask my team to strike it from our script and use a different declaration method.

So that'd be question one: when was our introduced in Perl? I do know that it is possible it's been in Perl a very long time and I've just encountered it now -- I'm not that big headed...

My next question would be, is there a place, preferably online, where I can check Perl language constructs (keywords) against Perl versions, so I can know which version supports which construct? That would be really helpful. That way if I encounter another construct that I haven't seen before, I can at least lookup the language compatibility information so I don't have to keep posting those kinds of questions. Not to mention there may be a lot of developers who simply don't care when a construct (keyword) entered the language. I guess whether one cares about that or not depends on what one is using Perl for.

[larsen]

our appeared in Perl 5.6. You can check perldeltas to see what appeared and when.

Update: Just recalled an interesting node on the subject: Why is 'our' good?