[Chicago-talk] Global variable behavior

Mithun Bhattacharya inzoik at yahoo.com
Fri Mar 5 20:33:06 PST 2010


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 ourin a.plshould 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 $cvariable 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/20100305/9a5e2a91/attachment.html>


More information about the Chicago-talk mailing list