Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

clarify the comparison between 'our' and 'use vars' #22648

Open
wants to merge 1 commit into
base: blead
Choose a base branch
from
Open

clarify the comparison between 'our' and 'use vars' #22648

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions pod/perlfunc.pod
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5377,9 +5377,9 @@ values:

our ( undef, $min, $hour ) = localtime;

L<C<our>|/our VARLIST> differs from L<C<use vars>|vars>, which allows
use of an unqualified name I<only> within the affected package, but
across scopes.
L<C<our>|/our VARLIST> is lexically scoped, and as such differs from
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Won't lexical here raise more questions than it answers? my is for lexically scoped variables.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The problem is that with global variables "our" is lexcially scoped for the "handle" to the variable, not the variable itself. Global variables are created when used (in any way) and live in a global nested hash table (called the stash), which is entirely unrelated to whether you use "our" or "use vars" or use fully qualified notation, or if you use glob notation.

This means it is hard to talk about as the concepts do not map nicely to normal variables declarations in other languages (although there is some commonality with Javascript 'var' variables). Consider the following code.

package Whatever;
sub foo {};
{
   our $foo; # makes *Whatever::foo{SCALAR} available in the current scope under the unqualified name $foo.
}
# *Whatever::foo{SCALAR} still exists here, it is just that the var name $foo no longer aliases it.
{
   our $foo; # and we can access *Whatever::foo{SCALAR} here again, its the same var as the previous our
}

In this code we see two "our $foo" declarations, neither "creates" the variable $foo, (although they both ensure that it has been created), in fact it is created by the 'sub foo{}' statement when the Whatever::foo glob is created.

This is entirely unlike true lexical variables. Personally i prefer 'use vars' over 'our' I think the semantics map to what happens under the hood better.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Something like "it creates a lexically scoped alias"?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Leont that would make sense yes.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This means it is hard to talk about as the concepts do not map nicely to normal variables declarations in other languages

Perl our is pretty much C extern:

void foo(void) {
    {
        extern int bar;  // global variable, must be defined elsewhere
        printf("%d\n", bar);
    }
    bar = 0;  // error, bar is not in scope here
}

L<C<use vars>|vars>, which allows use of an unqualified name I<only>
within the affected package, without consideration for scopes.

=item pack TEMPLATE,LIST
X<pack>
Expand Down
Loading