'package' docs say 'our' is lexical (?)

[p5pRT]

Migrated from rt.perl.org#114674 (status was 'resolved')

Searchable as RT114674$

[p5pRT]

From @jimav

---

This is just a question, although it probably indicates that the
docs should be clarified.

perlfunc says​:
  A package statement affects dynamic variables only, including those
  you've used "local" on, but not lexical variables, which are
  created with "my", "state", or "our".

I'm confused about that last bit which says "our" creates a lexical.

Under what circumstances is 'our' not affected by the current package?

---

---

Flags​:
  category=core
  severity=none

---

Site configuration information for perl 5.14.2​:

Configured by Debian Project at Fri Aug 10 21​:43​:06 UTC 2012.

Summary of my perl5 (revision 5 version 14 subversion 2) configuration​:
 
  Platform​:
  osname=linux, osvers=2.6.42-26-generic, archname=x86_64-linux-gnu-thread-multi
  uname='linux allspice 2.6.42-26-generic #41-ubuntu smp thu jun 14 17​:49​:24 utc 2012 x86_64 x86_64 x86_64 gnulinux '
  config_args='-Dusethreads -Duselargefiles -Dccflags=-DDEBIAN -Dcccdlflags=-fPIC -Darchname=x86_64-linux-gnu -Dprefix=/usr -Dprivlib=/usr/share/perl/5.14 -Darchlib=/usr/lib/perl/5.14 -Dvendorprefix=/usr -Dvendorlib=/usr/share/perl5 -Dvendorarch=/usr/lib/perl5 -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl/5.14.2 -Dsitearch=/usr/local/lib/perl/5.14.2 -Dman1dir=/usr/share/man/man1 -Dman3dir=/usr/share/man/man3 -Dsiteman1dir=/usr/local/man/man1 -Dsiteman3dir=/usr/local/man/man3 -Duse64bitint -Dman1ext=1 -Dman3ext=3perl -Dpager=/usr/bin/sensible-pager -Uafs -Ud_csh -Ud_ualarm -Uusesfio -Uusenm -Ui_libutil -DDEBUGGING=-g -Doptimize=-O2 -Duseshrplib -Dlibperl=libperl.so.5.14.2 -des'
  hint=recommended, useposix=true, d_sigaction=define
  useithreads=define, usemultiplicity=define
  useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
  use64bitint=define, use64bitall=define, uselongdouble=undef
  usemymalloc=n, bincompat5005=undef
  Compiler​:
  cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
  optimize='-O2 -g',
  cppflags='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
  ccversion='', gccversion='4.6.3', gccosandvers=''
  intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
  d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
  ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
  alignbytes=8, prototype=define
  Linker and Libraries​:
  ld='cc', ldflags =' -fstack-protector -L/usr/local/lib'
  libpth=/usr/local/lib /lib/x86_64-linux-gnu /lib/../lib /usr/lib/x86_64-linux-gnu /usr/lib/../lib /lib /usr/lib
  libs=-lgdbm -lgdbm_compat -ldb -ldl -lm -lpthread -lc -lcrypt
  perllibs=-ldl -lm -lpthread -lc -lcrypt
  libc=, so=so, useshrplib=true, libperl=libperl.so.5.14.2
  gnulibc_version='2.15'
  Dynamic Linking​:
  dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
  cccdlflags='-fPIC', lddlflags='-shared -O2 -g -L/usr/local/lib -fstack-protector'

Locally applied patches​:
 

---

@​INC for perl 5.14.2​:
  /home/jima/local/lib/perl/5.14.2
  /home/jima/local/lib/perl
  /home/jima/local/share/perl/5.14.2
  /home/jima/local/share/perl
  /home/jima/lib/perl
  /etc/perl
  /usr/local/lib/perl/5.14.2
  /usr/local/share/perl/5.14.2
  /usr/lib/perl5
  /usr/share/perl5
  /usr/lib/perl/5.14
  /usr/share/perl/5.14
  /usr/local/lib/site_perl
  .

---

Environment for perl 5.14.2​:
  HOME=/home/jima
  LANG=en_US.UTF-8
  LANGUAGE=
  LD_LIBRARY_PATH=/home/jima/local/lib
  LOGDIR (unset)
  PATH=/home/jima/bin​:/home/jima/local/bin​:/home/jima/jima_tools/bin​:/usr/bin​:/bin​:/usr/sbin​:/sbin​:/usr/bin/X11​:/usr/local/bin​:/usr/local/sbin​:/usr/games​:.
  PERL5LIB=/home/jima/local/lib/perl​:/home/jima/local/share/perl​:/home/jima/lib/perl
  PERL_BADLANG (unset)
  SHELL=/bin/bash

[p5pRT]

From @rjbs

package X;
our $X;
$X = 1;
package Y;
print $X;

The name $X is lexically scoped and refers to the package variable $X in the package in which it
was declared.

[p5pRT]

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

[p5pRT]

From @ap

Also,

  use strict;
  { our $x = 1 }
  print $x;

dies with an undeclared variable error.

[p5pRT]

From @ikegami

It is correct. C<our> creates a lexical variable which is aliased to a
package variable. Others have provided examples.

- Eric

[p5pRT]

From @cpansprout

On Thu Aug 30 16​:04​:51 2012, ikegami@​adaelis.com wrote​:

It is correct. C<our> creates a lexical variable which is aliased to a
package variable. Others have provided examples.

And the documentation for ‘our’ was expanded in bleadperl recently, when
someone asked almost the same question. So I am marking this as resolved.

--

Father Chrysostomos

[p5pRT]

@cpansprout - Status changed from 'open' to 'resolved'

[p5pRT]

From perl-diddler@tlinx.org

Father Chrysostomos via RT wrote​:

On Thu Aug 30 16​:04​:51 2012, ikegami@​adaelis.com wrote​:

It is correct. C<our> creates a lexical variable which is aliased to a
package variable. Others have provided examples.

And the documentation for ‘our’ was expanded in bleadperl recently, when
someone asked almost the same question. So I am marking this as resolved.

Was it also mentioned that if they want package variables, they need to use
"use vars"? and was the deprecation notation removed from use vars?

[p5pRT]

From mail@steffen-mueller.net

On 09/04/2012 06​:00 AM, Linda W wrote​:

Father Chrysostomos via RT wrote​:

On Thu Aug 30 16​:04​:51 2012,ikegami@​adaelis.com wrote​:

It is correct. C<our> creates a lexical variable which is aliased to a
package variable. Others have provided examples.

And the documentation for ‘our’ was expanded in bleadperl recently, when
someone asked almost the same question. So I am marking this as resolved.

Was it also mentioned that if they want package variables, they need to use
"use vars"? and was the deprecation notation removed from use vars?

Please read what ikegami wrote. 'our' creates a lexical alias to a
package variable. It's a package variable alright underneath! It's just
that (warning-less) access to it is set up in a lexical scope.

If you want package variables, declare that you intend to use it using
'our'. From outside the package, use fully qualified names (also without
warning, except maybe "used only once").

Thus, the documentation is correct since the effect of 'our' is lexical.
Not a bug.

--Steffen

[p5pRT]

From @ap

* Linda W <perl-diddler@​tlinx.org> [2012-09-04 06​:05]​:

Was it also mentioned that if they want package variables, they need
to use "use vars"? and was the deprecation notation removed from use
vars?

You are utterly confused.

[p5pRT]

From @dmcbride

On Tuesday September 4 2012 4​:28​:22 PM Aristotle Pagaltzis wrote​:

* Linda W <perl-diddler@​tlinx.org> [2012-09-04 06​:05]​:

Was it also mentioned that if they want package variables, they need
to use "use vars"? and was the deprecation notation removed from use
vars?

You are utterly confused.

To be fair, when I first read about "our", it was being billed, probably
incorrectly, as a replacement to "use vars" (which I already generally avoided
for whatever reason). The "lexical" bit, and its implications, were not clear
to me until just recently as it has ben explained a few times on this list
since I've been watching (and that only goes back to April).

Basically, the impression I got is that it's a drop-in replacement for use
vars. It is not, though for most of us, it's close enough - most people
should not be putting multiple package's in a single file, and then it comes
out to more or less the same thing. It's still a bit different in that it's
only "visible" from that point on, etc., where use vars would affect the whole
file, er package, no matter where it's placed, again, with a few exceptions
such as BEGIN blocks before the use vars. Largely, most of that doesn't make
any difference.

So, when people get into those rare cases, I have to admit understanding their
confusion simply because I shared it. And, until I have some actual real use
of our such that the difference matters under my belt to cement the ideas in my
head, I'm still a bit fuzzy on it.

Now, does the documentation need improving? Not necessarily. I think there
was a marketing problem at the beginning​: "our" is not a replacement for "our
vars", it's the New and Improved way of accomplishing the goal. Except that
it really is New, and really is Improved.

The docs now have been modified many times since our was introduced due to this
confusion. If the docs were to be further updated now, the only thing really
missing from "perldoc -f our", IMO, might be to explicitly contrast our vs use
vars and how our is the Improved version of use vars. Though that might be
better put in vars' docs instead, that would create a circular reference (vars
points users to our, and then our would need to point users back to vars),
which may be considered annoying by some (not me).

But, really, I know, now, that I'm operating with some really old knowledge.
The confusion is, I think, fair, based on how our was introduced, at least to
me (on perlmonks, IIRC).

"The vars pragma is obsolete because C<our> accomplishes the same goals, and
does so in a different but better way." (And maybe an example of how multiple
packages in the same file work.)

[p5pRT]

From perl-diddler@tlinx.org

Steffen Mueller wrote​:

On 09/04/2012 06​:00 AM, Linda W wrote

Was it also mentioned that if they want package variables, they need
to use
"use vars"? and was the deprecation notation removed from use vars?

Please read what ikegami wrote. 'our' creates a lexical alias to a
package variable. It's a package variable alright underneath! It's
just that (warning-less) access to it is set up in a lexical scope.

---

  Right. But if you only want a package scoped package variable,
you need to use "use vars".

  That's the point. "use vars" give you access to "package-scoped"
variables,
while "our" gives you access to package variables (hopefully the same
ones?), but lexically scoped.

If you want package variables, declare that you intend to use it using
'our'. From outside the package, use fully qualified names (also
without warning, except maybe "used only once").

---

  You didn't address the case of using a variable that goes out of
scope when
the package changes but the lexical scope does not.

Thus, the documentation is correct since the effect of 'our' is
lexical. Not a bug.

---

  I, wasn't saying it was -- I was emphasizing that to get package-scoped
variables rather than lexically scoped package variables, one needs to use
"use vars" -- which ideally would be shortened to 'var or vars', but
that would
be too much like 'sensible', since it's a bit of a 'hole' in the
language to have to use a pragma to use package-scoped variables.

  Too many people make the mistake of believing that 'our' defines
package variables when they don't -- they provide a lexically scoped
alias to the package var by the same name.

  That confusion and the lack of the clear function of 'use vars' (to
the point that someone thought that "our" was a replacement for "use
vars" -- when clearly they don't operate the same way), is the bug in
the documentation that
clarification was asked about.

[p5pRT]

From @doy

On Tue, Sep 04, 2012 at 10​:31​:25AM -0700, Linda W wrote​:

Steffen Mueller wrote​:

On 09/04/2012 06​:00 AM, Linda W wrote

Was it also mentioned that if they want package variables, they
need to use
"use vars"? and was the deprecation notation removed from use vars?

Please read what ikegami wrote. 'our' creates a lexical alias to a
package variable. It's a package variable alright underneath! It's
just that (warning-less) access to it is set up in a lexical
scope.
----
Right. But if you only want a package scoped package variable,
you need to use "use vars".

That's the point. "use vars" give you access to "package-scoped"
variables,
while "our" gives you access to package variables (hopefully the
same ones?), but lexically scoped.

If you want package variables, declare that you intend to use it using
'our'. From outside the package, use fully qualified names (also
without warning, except maybe "used only once").
----
You didn't address the case of using a variable that goes out of
scope when
the package changes but the lexical scope does not.

Thus, the documentation is correct since the effect of 'our' is
lexical. Not a bug.
----
I, wasn't saying it was -- I was emphasizing that to get package-scoped
variables rather than lexically scoped package variables, one needs to use
"use vars" -- which ideally would be shortened to 'var or vars', but
that would
be too much like 'sensible', since it's a bit of a 'hole' in the
language to have to use a pragma to use package-scoped variables.

Too many people make the mistake of believing that 'our' defines
package variables when they don't -- they provide a lexically scoped
alias to the package var by the same name.

That confusion and the lack of the clear function of 'use vars'
(to the point that someone thought that "our" was a replacement for
"use vars" -- when clearly they don't operate the same way), is the
bug in the documentation that
clarification was asked about.

The reason it works like this is because a lexically scoped alias to the
package variable is *almost always* what people actually want.
Everything in the language has been slowly moving to be as lexically
scoped as possible over the course if its life, and I don't think we
need to be encouraging moving backwards in that sense. 'use vars' is a
discouraged pragma rather than a language feature like 'our' because we
want to encourage people to use lexicals in preference to 'package
scoped' things. It was never intended to be a drop-in replacement.

-doy

[p5pRT]

From perl-diddler@tlinx.org

Jesse Luehrs wrote​:

That confusion and the lack of the clear function of 'use vars'
(to the point that someone thought that "our" was a replacement for
"use vars" -- when clearly they don't operate the same way), is the
bug in the documentation that
clarification was asked about.

The reason it works like this is because a lexically scoped alias to the
package variable is *almost always* what people actually want.

---

  I disagree -- If I want a lexically scoped variable, I put my package
in braces​: (which I now, usually do, otherwise the effect's of 'our'
give unexpected results -- usually bad ones).

{package foobar;
}

If I explicitly use packages without the braces, -- which I might
do if the package was the only package in a file or 'main',
I'd want my package var to be a package var.

Without braces 'our' gives you a file-scoped var in whatever
package happens to be in effect at the time you use it. That's
hardly what I would call "clear" behavior, and is *almost always*
not to be what a person wants unless they place it in the right package
(perhaps before the very first package statement -- making it a file-level
variable).

[p5pRT]

From @doy

On Tue, Sep 04, 2012 at 10​:52​:38AM -0700, Linda W wrote​:

Jesse Luehrs wrote​:

That confusion and the lack of the clear function of 'use vars'
(to the point that someone thought that "our" was a replacement for
"use vars" -- when clearly they don't operate the same way), is the
bug in the documentation that
clarification was asked about.

The reason it works like this is because a lexically scoped alias to the
package variable is *almost always* what people actually want.
----
I disagree -- If I want a lexically scoped variable, I put my package
in braces​: (which I now, usually do, otherwise the effect's of 'our'
give unexpected results -- usually bad ones).

{package foobar;
}

If I explicitly use packages without the braces, -- which I might
do if the package was the only package in a file or 'main',
I'd want my package var to be a package var.

Without braces 'our' gives you a file-scoped var in whatever
package happens to be in effect at the time you use it. That's
hardly what I would call "clear" behavior, and is *almost always*
not to be what a person wants unless they place it in the right package
(perhaps before the very first package statement -- making it a file-level
variable).

I wonder if the right answer here is to make using an 'our' variable in
a different package than the one it is an alias to into a warning? This
would probably be pretty easy to do.

-doy

[p5pRT]

From @ikegami

On Tue, Sep 4, 2012 at 1​:31 PM, Linda W <perl-diddler@​tlinx.org> wrote​:

Steffen Mueller wrote​:

On 09/04/2012 06​:00 AM, Linda W wrote

Was it also mentioned that if they want package variables, they need to
use
"use vars"? and was the deprecation notation removed from use vars?

Please read what ikegami wrote. 'our' creates a lexical alias to a
package variable. It's a package variable alright underneath! It's just
that (warning-less) access to it is set up in a lexical scope.

----
Right. But if you only want a package scoped package variable,
you need to use "use vars".

Nothing provides package-scoped variables. Package variables are global
(visible everywhere).

That's the point. "use vars" give you access to "package-scoped"
variables,
while "our" gives you access to package variables (hopefully the same
ones?), but lexically scoped.

No, both "use vars" and "our" provides access to (the same) package
variables.

[p5pRT]

From perl-diddler@tlinx.org

Eric Brine wrote​:

No, both "use vars" and "our" provides access to (the same) package
variables.
If you are going to keep making groundless statements, go do so
somewhere else​:

perl -e '
package one;
use vars '$b';
our $c=1;
$b=1;

package two;
print "c=$c,b=$b\n";
'
c=1,b=

---

Clearly you are either don't know what you are taking about or are
deliberately
attempting to be misleading. Either way, I find your comments
obstructive to
reasonable dialogue.

[p5pRT]

From @rjbs

* Linda W <perl-diddler@​tlinx.org> [2012-09-04T14​:14​:55]

Eric Brine wrote​:

No, both "use vars" and "our" provides access to (the same)
package variables.
If you are going to keep making groundless statements, go do so
somewhere else​:

Linda, you are mistaken.

perl -e '
package one;
use vars '$b';
our $c=1;
$b=1;

package two;
print "c=$c,b=$b\n";
'
c=1,b=

This is not the right program to demonstrate the truth of what Eric said.

  ~$ perl -e '
  package one;
  use vars q{$b};
  our $c =1 ;
  $b = 1;
 
  package two;
  print "c=$one​::c,b=$one​::b\n";
  '
  c=1,b=1

"use vars" lets you use the name $b to refer to $one​::b without qualification
while 'one' is the current package. Nonetheless, $one​::b, as a package
variable, is globally available with or without use vars.

The variable's accessibility is still global. Only the scope and availability
of the names changes.

Clearly you are either don't know what you are taking about or are
deliberately attempting to be misleading. Either way, I find your comments
obstructive to reasonable dialogue.

Tread carefully.

--
rjbs

[p5pRT]

From @Leont

On Tue, Sep 4, 2012 at 7​:52 PM, Linda W <perl-diddler@​tlinx.org> wrote​:

I disagree \-\- If I want a lexically scoped variable\, I put my package

in braces​: (which I now, usually do, otherwise the effect's of 'our'
give unexpected results -- usually bad ones).

He said almost always, not always. You happen to have a style that is
different from what most people use, probably because that style
(putting multiple modules in one file, using package variables unless
strictly necessary) is generally discouraged for various reasons.

Within your style what you're asking for makes sense, but the
consensus is that your style is not the way to go forward.

Leon

[p5pRT]

From @dmcbride

On Tuesday September 4 2012 11​:14​:55 AM Linda W wrote​:

Eric Brine wrote​:

No, both "use vars" and "our" provides access to (the same) package
variables.

If you are going to keep making groundless statements, go do so
somewhere else​:

Linda, have you considered taking your questions to a forum better suited for
learning than the perl5-porters mailing list? I would suggest perlmonks.org.

perl -e '

package one;
use vars '$b';
our $c=1;
$b=1;

package two;
print "c=$c,b=$b\n";
'
c=1,b=

This doesn't prove what you think it does. Eric is correct, they are
providing access to the same package variables. However, their *scope* is
entirely different. All you've shown is that our's scope is to the end of the
file (more testing can show this is lexical, but your example is not exhaustive
for that claim) while use vars' scope is limited to the current package
(again, not exhaustively, but close enough) and thus doesn't show up in your
second package.

This might be a bit more clear​:

$ perl -Mstrict -Mwarnings -E '
package one;
use vars qw($two);
$two = 3;
say $two;
our $two;
say $two;
package fourty;
say $two;
'
3
3
3

This might be a bit more clear​: first we enable strict and warnings so you can
see any errors (there aren't any). Without that, there's much less impetus
for use vars (or our, except that our allows the global variable from the
current package to show up in any other package in the current lexical scope,
the part that may be confusing and/or surprising).

We then set it. Without the use vars, $two = 3 would fail, but without
strict, the use vars wouldn't be required.

We spit it out, just so we see it.

Then we create the lexical alias and say it. Unsurprisingly, it's the same.

We then switch packages and say it again. Due to the lexical scope here, we
see the same value again. Without the our $two above, this would be spitting
out undef (warning time again), as we would then be looking for $fourty​::two,
instead of the lexical $two, which was originally an alias to $one​::two.

Clearly you are either don't know what you are taking about or are
deliberately
attempting to be misleading. Either way, I find your comments
obstructive to
reasonable dialogue.

Not clear at all. What's clear is that you didn't understand Eric's
explanation. Further, it's also clear that you chose to attack Eric rather
than attempt to understand him.

I would really appreciate it if you could take your "I don't understand Perl"
questions to a more appropriate forum, such as perlmonks.org,
stackoverflow.com, or #perl on either irc.perl.org or freenode. The topic of
your posts are tangential to the topic of this mailing list, but the content
of your posts are completely off-topic.

Thank you.

[p5pRT]

From @ikegami

On Tue, Sep 4, 2012 at 2​:14 PM, Linda W <perl-diddler@​tlinx.org> wrote​:

Eric Brine wrote​:

No, both "use vars" and "our" provides access to (the same) package
variables.

If you are going to keep making groundless statements, go do so somewhere
else​:

perl -e '

package one;
use vars '$b';
our $c=1;
$b=1;

package two;
print "c=$c,b=$b\n";
'
c=1,b=

-------------
Clearly you are either don't know what you are taking about or are
deliberately
attempting to be misleading. Either way, I find your comments obstructive
to
reasonable dialogue.

You didn't print The $b of <<use vars>>. That's a different $b you printed.

[p5pRT]

From @ikegami

On Tue, Sep 4, 2012 at 2​:40 PM, Eric Brine <ikegami@​adaelis.com> wrote​:

On Tue, Sep 4, 2012 at 2​:14 PM, Linda W <perl-diddler@​tlinx.org> wrote​:

Eric Brine wrote​:

No, both "use vars" and "our" provides access to (the same) package
variables.

If you are going to keep making groundless statements, go do so somewhere
else​:

perl -e '

package one;
use vars '$b';
our $c=1;
$b=1;

package two;
print "c=$c,b=$b\n";
'
c=1,b=

-------------
Clearly you are either don't know what you are taking about or are
deliberately
attempting to be misleading. Either way, I find your comments
obstructive to
reasonable dialogue.

You didn't print The $b of <<use vars>>. That's a different $b you printed.

perl -e '
package one;
use vars '$b';
our $c;
$b=123;

package two;
print "c=$c\n";
'
c=123

[p5pRT]

From @ikegami

Ignore my last message. Tried to convert her code into something that made
sense and failed. To show they use the same variable, one compares the
output of​:

perl -e'
package one;
use vars qw( $c );
$c = 123;
print "$one​::c\n";
'

perl -e'
package one;
our $c;
$c = 123;
print "$one​::c\n";
'

[p5pRT]

From @ap

* Darin McBride <dmcbride@​cpan.org> [2012-09-04 18​:30]​:

On Tuesday September 4 2012 4​:28​:22 PM Aristotle Pagaltzis wrote​:

* Linda W <perl-diddler@​tlinx.org> [2012-09-04 06​:05]​:

Was it also mentioned that if they want package variables, they
need to use "use vars"? and was the deprecation notation removed
from use vars?

You are utterly confused.

To be fair

It is not a matter of fairness. I mind not her confusion but the fact
that her questions are loaded when both of their premises are false.

[p5pRT]

From perl-diddler@tlinx.org

Eric Brine wrote​:

You didn't print The $b of <<use vars>>. That's a different $b you
printed.
<linda-like example, complete with linda-like typos/brainos, elided>
Eric Brine wrote​:
Ignore my last message. Tried to convert her code into something that
made sense and failed. To show they use the same variable, one
compares the output of​: ... >irrelevant example elided>
That's nice.

My code didn't made sense to you, as I may have used some uncommon concepts
in my code. I hope the following better illustrates the differences and
shows that "our" is not a replacement for "vars", and that it can
be somewhat counter intuitive, *if* you expect them to be equivalent.

#!/usr/bin/perl -l
use vars '$b';
$b="global";
{ package one;
  use vars '$b';
  $b="var";
  { package two;
  our $b="our";
  print __LINE__.") two-b=$b";

  package one;
  print __LINE__.") In package one, b=$b";
  }
  print __LINE__.") still in package 1, b=$b";
  { package one;
  our $b="our";
  }
  print __LINE__.") another try b=$b";
}
print __LINE__.") last package statement was \"one\", but lexically in
main";
print __LINE__.") mainb=$b";
package one;
print __LINE__.") package1-b=$b";
our $b;
print __LINE__.") our b=$b";

---

9) two-b=our
12) In package one, b=our
14) still in package 1, b=var
18) another try b=our
20) last package statement was "one", but lexically in main
21) mainb=global
23) package1-b=our
25) our b=our

---

Note in package two when we print $b, we see our --
but when we revert to package one -- the lexical scope of package two is
still active, so we get "two's value of 'b'.

closing the scope, we see package one's be is still 'var'.

using a package-one scoped assignment to "our $b", it now gets the value
"our"
and retains it through the program -- except in 'main', where it
prints the 'global value'.

The above shows the package scoped nature of "use vars";
how an interior lexical scoped 'our $b' overrides the lexical scoping of
the package (as it is an outer scoping).

I don't see any bugs above -- just documentation needed to
note that "use vars" vars are packagely scoped -- ending at the next package
statement UNLESS brace-scoping is overriding the natural package scoping.

[p5pRT]

From @doy

On Tue, Sep 04, 2012 at 04​:06​:19PM -0700, Linda W wrote​:

I don't see any bugs above -- just documentation needed to
note that "use vars" vars are packagely scoped -- ending at the next package
statement UNLESS brace-scoping is overriding the natural package scoping.

But again, as has been explained several times over at this point, this
is not what is happening at all.

  package P1;
  use vars '$a';
  $a = 1;
  print "a = '$a'\n";

  package P2;
  print "a = '$a'\n";

  package P1;
  print "a = '$a'\n";

prints

  a = '1'
  a = ''
  a = '1'

'use vars' has nothing at all to do with scoping.

-doy

[p5pRT]

From perl-diddler@tlinx.org

Jesse Luehrs wrote​:

On Tue, Sep 04, 2012 at 04​:06​:19PM -0700, Linda W wrote​:

I don't see any bugs above -- just documentation needed to
note that "use vars" vars are packagely scoped -- ending at the next package
statement UNLESS brace-scoping is overriding the natural package scoping.

But again, as has been explained several times over at this point, this
is not what is happening at all.

package P1;
use vars '$a';
$a = 1;
print "a = '$a'\n";

package P2;
print "a = '$a'\n";

package P1;
print "a = '$a'\n";

prints

a = '1'
a = ''
a = '1'

'use vars' has nothing at all to do with scoping.

---

  It is valid within package scoping. How is that "nothing at all to
do with scoping".

When you declare package P2, the namespace of package P1 goes "out of
scope".
When you declare package P1 again, that namespace comes back into scope and
you can again access vars you set under use vars earlier.

How is that not scoping by namespace?

[p5pRT]

From @doy

On Tue, Sep 04, 2012 at 04​:26​:02PM -0700, Linda W wrote​:

Jesse Luehrs wrote​:

On Tue, Sep 04, 2012 at 04​:06​:19PM -0700, Linda W wrote​:

I don't see any bugs above -- just documentation needed to
note that "use vars" vars are packagely scoped -- ending at the next package
statement UNLESS brace-scoping is overriding the natural package scoping.

But again, as has been explained several times over at this point, this
is not what is happening at all.

package P1;
use vars '$a';
$a = 1;
print "a = '$a'\n";

package P2;
print "a = '$a'\n";

package P1;
print "a = '$a'\n";

prints

a = '1'
a = ''
a = '1'

'use vars' has nothing at all to do with scoping.
----
It is valid within package scoping. How is that "nothing at all to
do with scoping".

When you declare package P2, the namespace of package P1 goes "out
of scope".
When you declare package P1 again, that namespace comes back into scope and
you can again access vars you set under use vars earlier.

How is that not scoping by namespace?

Try running that without the 'use vars' statement - you'll get the exact
same results (as long as you don't 'use strict'). While package scoped
variables do exist, 'use vars' has nothing to do with the scoping at
all.

-doy

[p5pRT]

From @ikegami

On Tue, Sep 4, 2012 at 7​:06 PM, Linda W <perl-diddler@​tlinx.org> wrote​:

**
My code didn't made sense to you

Every time you reply to me, you say I said things you didn't Stop being
such a jerk

It's a clear demosntration that our variables are lexical, but you were
trying to prove that our $c didn't access a package variable. As such, it
made no sense for you to post what you posted.

[p5pRT]

From @jimav

I am the original poster of this bug.

Thank you to everyone who has contributed. 
I now request that this thread be closed, and that no more posts be sent to this bug.

Thank you very much.

-Jim Avera

[p5pRT]

From perl-diddler@tlinx.org

Eric Brine wrote​:

On Tue, Sep 4, 2012 at 7​:06 PM, Linda W <perl-diddler@​tlinx.org
<mailto​:perl-diddler@​tlinx.org>> wrote​:

My code didn't made sense to you

Every time you reply to me, you say I said things you didn't Stop
being such a jerk

---

  Just because I call you on your putting words in my mouth, I'm a jerk?
Stop claiming I said things I didn't and I won't respond that way. But you
do it all the time, like below​:

It's a clear demosntration that our variables are lexical, but you
were trying to prove that our $c didn't access a package variable. As
such, it made no sense for you to post what you posted.
You make a statement that I was trying to prove something that I wasn't
saying,
claiming or trying to prove at all. That you put such garbage into my
mouth
on a regular basis disgusts me no end.

My point was that the vars used by "use vars" do not behave the same way
as one's declared by 'our'. My example showed that. Where you get that I'm
trying to prove something completely different that what I was talking
about is beyond me.

As someone else points out 'use vars' permit you to use
package vars without hitting warnings.

They only allow you to access vars in the package .. not by braced-scope.

They ARE the same variables... I *hoped* and *assumed* they were (though
not until I tested it was I sure)... But I was never under the impression
that they didn't refer to the same variable --- just that
the scoping rules of the two are different.

And by scoping I mean use vars allows you to access package vars in
the currently active package w/o warnings.