Front page | perl.perl5.porters |
Postings from November 2016
Re: [perl #129345] perlmod doc bug wrt package scope
November 24, 2016 19:24
Re: [perl #129345] perlmod doc bug wrt package scope
Message ID: CANgJU+UNdNz8nV+6KXJGBb9eEvTWrGwheUESPEVrRUnGRH4O3Q@mail.gmail.com
On 24 November 2016 at 18:20, David Nicol <firstname.lastname@example.org> wrote:
> On Thu, Nov 24, 2016 at 4:12 AM, demerphq <email@example.com> wrote:
>>> are all blocks compilation units?
>> I would not say so. I would say compilation unit is something akin to
>> "statement", but includes the use of eval TEXT and do BLOCK, do FILE,
>> and etc.
>>> if a package statement affects at a compilation
>>> unit granularity, how can it be used to change namespace in the middle
>>> of a block?
>> Because compilation unit includes the statement.
> We (you and I) appear to be in agreement in favor of concerning
> removing "compilation unit" from this document.
I definitely think documentation that explains what is going on
without using that term is to be preferred over documentation that
does use it. So yes. :-)
>> I think the documentation should say something like
>> "the package statement determines the namespace for unqualified global
>> variables and subroutines used or declared after it in the same
>> lexical scope."
>> that is, it should make it clear that it is lexically scoped, and it
>> should make clear that it affects the declaration of things as well as
>> their reference.
> Works for me
>> Also, I would avoid the term dynamic variables in favour of the term
>> global variables. I don't think it helps introducing an orthagonal
>> concept to the discussion, especially when dynamic scoping is not
>> restricted to global variables, but package is.
> Have you any explanation of where the "in fact, Perl has no such thing
> as global variables" business, that I struck in my draft patch, came
> from? In my parlance, package a/k/a dynamic a/k/a symbol table a/k/a
> "global" variables are all the same thing in Perl, and the only thing
> C<package> does is specify where unqualified ones go.
It was introduced in 5.001. So soon after the introduction of
lexically scoped variables and the switch from Perl 4 namespace
management to Perl 5 management.
Author: Larry Wall <firstname.lastname@example.org>
Date: Sun Mar 12 22:32:14 1995 -0800
[See the Changes file for a list of changes]
diff --git a/pod/perlmod.pod b/pod/perlmod.pod
index d804b1e..dc825d6 100644
@@ -6,8 +6,10 @@ perlmod - Perl modules (packages)
-Perl provides a mechanism for alternate namespaces to protect packages
-from stomping on each others variables. By default, a Perl script starts
+Perl provides a mechanism for alternative namespaces to protect packages
+from stomping on each others variables. In fact, apart from certain magical
+variables, there's really no such thing as a global variable in Perl.
+By default, a Perl script starts
compiling into the package known as C<main>. You can switch namespaces
using the C<package> declaration. The scope of the package declaration is
from the declaration itself to the end of the enclosing block (the same
Which when i compare it to now:
Perl provides a mechanism for alternative namespaces to protect
packages from stomping on each other's variables. In fact, there's
really no such thing as a global variable in Perl. The package
statement declares the compilation unit as being in the given
namespace. The scope of the package declaration is from the
declaration itself through the end of the enclosing block, C<eval>,
reads (to me) slightly differently. The original sentence reads
"In fact, apart from certain magical variables, there's really no such
thing as a global variable in Perl."
which to me, combined with the context established by the preceding
sentence, clearly refers to the fact that all non-lexical vars (my
vars) are in a specific package.
In the modern version it reads
"In fact, there's really no such thing as a global variable in Perl."
The reference to certain magic variables (which are forced to main),
has been removed, and with it the context that we are talking about
which namespace vars are in. The way I read the original language
suggests to me that Perl 4, which I have never used, had a single
Regardless the entire opening paragraph of perlmod reads to me like it
was written for someone migrating from Perl 4, and it should be
rewritten completely as if it were going to be read by
someone who had never used perl, (or used only used "modern" perl's)
>>> "being in the given namespace" doesn't make it clear that there is
>>> only one namespace active for any statement.
>> I disagree. While I am fine with you rewording it, I think the use of
>> the singular there is very clear.
> Wouldn't make it clear to my hypothetical thick-skulled person who
> insists on imagining that "nested packages" means unqualified names
> not defined in the inner package will resolve to their defined
> co-nominees in the outer.
I am fine with rewording it, I just wanted to be clear I think that it
was unambiguous, and thus if you change it we need to preserve the
original meaning (which you were going to do , but anyway).
>> Some of your other criticisms are more compelling. "compilation unit"
>> is not a great term.
>> I wonder if we should use the term "namespace" at all or if we do if
>> we should document the relationship between namespaces and nested
> how about "prefix" ?
Yeah, I thought of that, but it doesn't do it for me.
>> I guess some of the problem here comes from the fact that the package
>> variable is lexically scoped, but the property it affects is the rule
>> for global variable lookup. :-)
> There you go again with the global variables. In fact there is no such
> thing in Perl, haven't you read the documentation? <g/>
Lets get rid of that language. :-)
perl -Mre=debug -e "/just|another|perl|hacker/"