in reply to Re^2: problem with global variables going out of scope
in thread problem with global variables going out of scope

I think of our as a lexically scoped directive similar to no strict 'vars'. The difference is that it only applies to the specified variables.

You think of our as creating a lexically scoped variable which is aliased to a package variable.

I don't agree with you. If the variable was lexically scoped, it wouldn't be possible to use it beyond the end of the lexical scope, as shown in the following code: 

{ our $var = 20; }
print("$var\n");  # 20

[download]

Update: Cleaned up my post.

Replies are listed 'Best First'.
Re^4: problem with global variables going out of scope
by acid06 (Friar) on Mar 29, 2006 at 00:15 UTC
    I guess you're right.
    I didn't bother testing without use strict and this could would fail if it was in effect.

    However, this might be considered either a perl bug or a documentation glitch as perlfunc reads:

    "our" associates a simple name with a package variable in the current package for use within the current scope. When "use strict 'vars'" is in effect, "our" lets you use declared global variables without qualifying them with package names, within the lexical scope of the "our" declaration. In this way "our" differs from "use vars", which is package scoped.

    Unlike "my", which both allocates storage for a variable and associates a simple name with that storage for use within the current scope, "our" associates a simple name with a package variable in the current package, for use within the current scope. In other words, "our" has the same scoping rules as "my", but does not necessarily create a variable.


    acid06
    perl -e "print pack('h*', 16369646), scalar reverse $="
[reply]
[d/l]

In Section Seekers of Perl Wisdom