From @schwern

perlfunc/our sez​:

  The "our" declaration has no semantic effect unless "use strict vars" is
  in effect, in which case it lets you use the declared global variable
  without qualifying it with a package name.

Ok, so that means any program should work the same with or without the
"our" statement if 'strict vars' is off.

  our $foo = 42; # or just $foo 42
  print $foo;

Except its not true. perlfunc/our goes on to contradict itself in the
next paragraph.

  An "our" declaration declares a global variable that will be
  visible across its entire lexical scope, even across package
  boundaries.

Which means​:

  package Bar;
  our $foo = 42;
  package Foo;
  print $foo;

acts different from

  package Bar;
  $foo = 42;
  package Foo;
  print $foo;

strict or not.

I think the thing to do is to reword the first statement such that it no
longer declares our has no effect unless strict is on.

  When C<use strict vars> is in effect, the C<our> declaration lets you
  use the declared global variable without qualifying it with a package
  name.

--
Michael G Schwern schwern@​pobox.com http​://www.pobox.com/~schwern
'All anyone gets in a mirror is themselves,' she said. 'But what you
gets in a good gumbo is everything.'
  -- "Witches Abroad" by Terry Prachett

From @schwern

--- pod/perlfunc.pod	2005/07/13 21:05:44	1.1
+++ pod/perlfunc.pod	2005/07/13 21:06:18
@@ -3242,15 +3242,14 @@
 
 =item our TYPE EXPR : ATTRS
 
-An C<our> declares the listed variables to be valid globals within
-the enclosing block, file, or C<eval>.  That is, it has the same
-scoping rules as a "my" declaration, but does not create a local
-variable.  If more than one value is listed, the list must be placed
-in parentheses.  The C<our> declaration has no semantic effect unless
-"use strict vars" is in effect, in which case it lets you use the
-declared global variable without qualifying it with a package name.
-(But only within the lexical scope of the C<our> declaration.  In this
-it differs from "use vars", which is package scoped.)
+An C<our> declares the listed variables to be valid globals within the
+enclosing block, file, or C<eval>.  That is, it has the same scoping
+rules as a "my" declaration, but does not create a local variable.  If
+more than one value is listed, the list must be placed in parentheses.
+When C<use strict vars> is in effect, the C<our> declaration lets you
+use the declared global variable without qualifying it with a package
+name.  (But only within the lexical scope of the C<our> declaration.
+In this it differs from "use vars", which is package scoped.)
 
 An C<our> declaration declares a global variable that will be visible
 across its entire lexical scope, even across package boundaries.  The

From @ysth

On Wed, Jul 13, 2005 at 02​:08​:07PM -0700, Michael G Schwern wrote​:

I think the thing to do is to reword the first statement such that it no
longer declares our has no effect unless strict is on.

When C<use strict vars> is in effect, the C<our> declaration lets you
use the declared global variable without qualifying it with a package
name.

Wording looks good, but I'd prefer to see C<use strict 'vars'>.

The RT System itself - Status changed from 'new' to 'open'

From @schwern

[ysth - Wed Jul 13 14​:13​:53 2005]​:

Wording looks good, but I'd prefer to see C<use strict 'vars'>.

Here it is again with that fixed plus the simple explaination lifted
from Randal's column.
http​://www.stonehenge.com/merlyn/UnixReview/col54.html

I also clarified in the cross-package example that the $bar used in
package Bar refers to $Foo​::bar. Didn't feel it was entirely obvious.

C<our> associates a simple name with a package variable in the current
package for the remander of the lexical scope. The listed variables
are declared to be valid globals within the enclosing block, file, or
C<eval>. That is, it has the same scoping rules as a "my"
declaration, but does not create a local variable. When C<use strict
'vars'> is in effect, the C<our> declaration lets you use the declared
global variable without qualifying it with a package name. (But only
within the lexical scope of the C<our> declaration. In this it
differs from "use vars", which is package scoped.)

If more than one value is listed, the list must be placed in
parentheses.

  our $foo;
  our($bar, $baz);

An C<our> declaration declares a global variable that will be visible
across its entire lexical scope, even across package boundaries. The
package in which the variable is entered is determined at the point
of the declaration, not at the point of use. This means the following
behavior holds​:

  package Foo;
  our $bar; # declares $Foo​::bar for rest of lexical scope
  $bar = 20;

  package Bar;
  print $bar; # prints 20 as it refers to $Foo​::bar

From @schwern

--- pod/perlfunc.pod	2005/07/13 21:05:44	1.1
+++ pod/perlfunc.pod	2005/07/15 02:08:16
@@ -3242,15 +3242,21 @@
 
 =item our TYPE EXPR : ATTRS
 
-An C<our> declares the listed variables to be valid globals within
-the enclosing block, file, or C<eval>.  That is, it has the same
-scoping rules as a "my" declaration, but does not create a local
-variable.  If more than one value is listed, the list must be placed
-in parentheses.  The C<our> declaration has no semantic effect unless
-"use strict vars" is in effect, in which case it lets you use the
-declared global variable without qualifying it with a package name.
-(But only within the lexical scope of the C<our> declaration.  In this
-it differs from "use vars", which is package scoped.)
+C<our> associates a simple name with a package variable in the current
+package for the remander of the lexical scope.  The listed variables
+are declared to be valid globals within the enclosing block, file, or
+C<eval>.  That is, it has the same scoping rules as a "my"
+declaration, but does not create a local variable.  When C<use strict
+'vars'> is in effect, the C<our> declaration lets you use the declared
+global variable without qualifying it with a package name.  (But only
+within the lexical scope of the C<our> declaration.  In this it
+differs from "use vars", which is package scoped.)
+
+If more than one value is listed, the list must be placed in
+parentheses.
+
+    our $foo;
+    our($bar, $baz);
 
 An C<our> declaration declares a global variable that will be visible
 across its entire lexical scope, even across package boundaries.  The
@@ -3263,10 +3269,10 @@
     $bar = 20;
 
     package Bar;
-    print $bar;		# prints 20
+    print $bar;		# prints 20 as it refers to $Foo::bar
 
 Multiple C<our> declarations in the same lexical scope are allowed
-if they are in different packages.  If they happened to be in the same
+if they are in different packages.  If they happen to be in the same
 package, Perl will emit warnings if you have asked for them.
 
     use warnings;

From @steve-m-hay

Michael G Schwern via RT wrote​:

[ysth - Wed Jul 13 14​:13​:53 2005]​:

Wording looks good, but I'd prefer to see C<use strict 'vars'>.

Here it is again with that fixed plus the simple explaination lifted
from Randal's column.
http​://www.stonehenge.com/merlyn/UnixReview/col54.html

I also clarified in the cross-package example that the $bar used in
package Bar refers to $Foo​::bar. Didn't feel it was entirely obvious.

Thanks. Applied as change 25148.

Radan Computational Ltd.

The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses​: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.

From @steve-m-hay

Now fixed in bleadperl.

@steve-m-hay - Status changed from 'open' to 'resolved'