develooper Front page | perl.perl5.porters | Postings from July 2012

Re: [perl #113974] package NAMESPACE manpage comments

Thread Previous | Thread Next
From:
Linda W
Date:
July 5, 2012 15:44
Subject:
Re: [perl #113974] package NAMESPACE manpage comments
Message ID:
4FF618BA.7060503@tlinx.org
David Golden wrote:
> FWIW, in your A/B example, I would probably write it to have package B
> be a *nested* scope within package A, rather than having three
> successive scopes A/B/A.  For me, repeated namespaces in serial scopes
> are a code smell -- a sign that I haven't sufficiently modularized the
>   
----
    Is nested package scoping documented somewhere?...

    I get regularly flamed for just wanting to put multiple packages in 
the same file --
I can't imaging the reaction that would occur with I use nested packages...

    Generally I agree though main occurs by *default* at the top... 
where one
usually wants to put one's "main globals" -- or program constants that 
define
behavior for the program (when the program isn't sufficiently advanced 
to take options,
for example)... but I tend to be old school and prefer defining things 
B4 I use them --
meaning code for 'main' would go at the bottom.

    That's the only example I can think off off hand where I tend to 
split scope -- but
it does happen frequently and having variables declared one place not be 
declared the
other place ..


    Well, If I define a package in an object oriented language like C++ 
-- i.e.
things they call PACKAGE variables (which is what "our" variables are 
called under
"our" -- which sounds like it is more than a little misleading!)... then 
define more
of that package someplace else (another file, another part of same 
file...whatever),
I would expect those PACKAGE variables to be available to the 
PACKAGE!... not constrained
to a local definition.

    I don't even like the word "discouraged" -- because too many people, 
refer to
"our" as package variables -- Which they ARE -- "sorta", BUT...they 
continue on in the
current scope even into other packages.

So when you use an 'our' variable, it's not necessarily a package 
variable of the current
package!...

To quote 'Randal L 
Schwartz':(http://www.stonehenge.com/merlyn/UnixReview/col46.html)
  
   Some of the variables in a Perl program are /package variables/ (also 
called /symbol-table
   variables/). A    package variable's full name consists of a package 
prefix followed by the
   specific identifier for the     variable. The prefix is separated 
from the identifier by a double
   colon.

====
I.e. a package variable, according to Randal is a var: 
${__PACKAGENAME__."::var"};

which is *exactly* what "our" creates, but it is not really a package 
var, UNLESS you
scope your packages.  Example:
(sidenote: P is short-hand for something like print/say w/undef check).
#!/usr/bin/perl -w
use strict;
use P;
package default;
{  package A;
  use P;
  P "package ".__PACKAGE__." is the setter";
  our $foobar=22;
};
  our $wildcard="*";

package B;
use P;
P "now in package ".__PACKAGE__.".";
no strict 'refs';
  P "A::foobar=%s, wildcard=%s, and wc=%s\n",
          $A::foobar, $wildcard, $default::wildcard;
  printf "but not likely will B::wildcard work: %s\n",
    eval("\$"."B::wildcard")

------------------

So in package B, referencing a package var, 'A::foobar', references 'A' 
package variable.
and to reference wildcard, can use it with or without the 'default' prefix.

So somehow it just seem WRONG to be referring to 'our' vars as package 
variables
when really it is
"use vars" that are the true packgage variables that are (obsolete?)
or "discouraged"....

But when people want package variables -- what are they going to be
told to use?

our's?  when it's not?  or "use vars"  when it is?















Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About