[Chicago-talk] Global variable behavior

Sun Mar 7 17:12:43 PST 2010

Mithum,

You say:

*       . . . demonstrating that it is use warnings which would help more in
this scenario rather than use strict.

No, you haven't demonstrated that at all.

On the one hand, you are assuming that "require" is just like 'C' language
"#include" (a pre-processor directive,) but on the other hand you have ended
the module with "1;" which indicates you know that "require" is not just
like "#include".  The instruction "require" is not a pre-processing
directive, but rather, the required file is compiled and executed at the
time of inclusion, and the whole process retains the integrity of the file
as a unit of scope.  So . . .

>From my e-mail:

> Get in the habit of putting the following at the top of every file:

> 

>            use strict;

If you actually do that, i.e. if you put it at the head of the file
"newbie.pm", you will get this message:

Global symbol "$c" requires explicit package name at newbie.pm line 5.

Compilation failed in require at a.pl line 7.

That is a compile time message dealing with declaration.  By contrast, "use
warnings" is a run time check and has nothing to do with the declaration,
except that it calls attention to your mistaken belief that you initialized
something that you haven't.

By the way, I also put "use warnings" at the top of all my files during
development, and usually I leave it there.  For performance reasons some
people take it out aftter development is done if they have a performance
critical app - like I said, it is a run-time check.

Alexander Danel

  _____  

From: chicago-talk-bounces+danel=speakeasy.net at pm.org
[mailto:chicago-talk-bounces+danel=speakeasy.net at pm.org] On Behalf Of Mithun
Bhattacharya
Sent: Friday, March 05, 2010 10:33 PM
To: Chicago.pm chatter
Subject: Re: [Chicago-talk] Global variable behavior

Thanks for the input. I guess I took somethings for granted and didn't read
up the relevant sections carefully :)

I am not nitpicking here but I would like to share a few more things which
became more obvious to me - hopefully it will help others too.

New code follows
======================================================================
$ cat a.pl 
use strict;

push @INC, '.';

our $c = 15;

require newbie;
======================================================================

$ cat newbie.pm 
package newbie;

print "first attempt: " . $c . "\n";
print "second attempt: " . $::c . "\n";

1;
======================================================================

$ perl a.pl 
first attempt: 
second attempt: 15
======================================================================

$ perl -w a.pl 
Use of uninitialized value $newbie::c in concatenation (.) or string at
newbie.pm line 3.
first attempt: 
second attempt: 15
======================================================================

$ perl -v
This is perl, v5.10.0 built for x86_64-linux-thread-multi
======================================================================

I am just demonstrating that it is use warnings which would help more in
this scenario rather than use strict.

Something else which confused me after I started understanding our better
was the following - maybe someone can point out if I have miss-understood
anything.

As per perldoc for our

            "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.

The first paragraph seems to imply to me that our is for declaring a global
variable as most C developers tend to think of them. If I understand it
correctly our is always associated with a package - if we call our outside a
defined package as is the case in my sample it goes to the package main.

The second paragraph doesnt help me understand things any better other than
to say that my and our are similar in scope. I would like to quote from
http://stackoverflow.com/questions/845060/what-is-the-difference-between-my-
and-our-in-perl which says

Available since Perl 5, my is a way to declare:

    * non-package variables, that are
    * private,
    * new,
    * non-global variables,
    * separate from any package. So that the variable cannot be accessed in
the form of $package_name::variable.

On the other hand, our variables are:

    * package variables, and thus automatically
    * global variables,
    * definitely not private,
    * nor are they necessarily new; and they
    * can be accessed outside the package (or lexical scope) with the
qualified namespace, as $package_name::variable.

Personally the second explanation is much more easier for me to comprehend
than the perldoc but I suppose someone could elaborate what I might be
missing out on if I follow that explanation.

In any case thanks for listening to me and hopefully I am not making a fool
of myself here with perl basics.

- Mithun

  _____  

From: Alexander Danel <danel at speakeasy.net>
To: Chicago.pm chatter <chicago-talk at pm.org>
Sent: Wed, March 3, 2010 9:00:08 PM
Subject: Re: [Chicago-talk] Global variable behavior

Get in the habit of putting the following at the top of every file:

            use strict;

Try it.  It will inform you that you are implicitly doing just what you
claim you are not doing: you have declared (or, as you put it "redeclared")
the variable.  "Use strict" will protest because implicit declarations are
often an accident; which is clearly appropriate for your case.

By the way, I take exception to your statement  ". . . should make it global
across all name spaces."  No such concept exists in Perl.  You declared the
variable to be in the "main" namespace; which you seemingly understood when
you used "$::c", the naked double-colon being an alias for "main::".   The
package "main" is in force until you declare otherwise.

Alexander Danel

  _____  

From: chicago-talk-bounces+danel=speakeasy.net at pm.org
[mailto:chicago-talk-bounces+danel=speakeasy.net at pm.org] On Behalf Of Mithun
Bhattacharya
Sent: Wednesday, March 03, 2010 8:20 PM
To: chicago-talk at pm.org
Subject: [Chicago-talk] Global variable behavior

Hi Everyone,

A piece of my code is behaving in a way I didn't expect and I was hoping
someone could enlighten me as to why..

-------------------------------------
$ cat a.pl 
push @INC, '.';

our $c = 15;

require newbie;
-------------------------------------
$ cat newbie.pm 
package newbie;

print "first attempt: " . $c . "\n";
print "second attempt: " . $::c . "\n";

1;
-------------------------------------
$ perl a.pl 
first attempt: 
second attempt: 15
-------------------------------------

The way I see it the our in a.pl should make it global across all
namespaces. The second attempt does seem to say that did take place. What I
am not sure is why the $c variable has become local in scope even though I
haven't re-declared or redefined it in any way inside newbie.pm.

- Mithun

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/chicago-talk/attachments/20100307/2742c88c/attachment-0001.html>