develooper Front page | perl.perl5.porters | Postings from November 2016

Re: [perl #129345] perlmod doc bug wrt package scope

Thread Previous | Thread Next
November 24, 2016 10:12
Re: [perl #129345] perlmod doc bug wrt package scope
Message ID:
On 23 November 2016 at 21:25, David Nicol <> wrote:
> yes, of course, that's how it works, and it looks to me like you can't
> see that it can be misread this way, because you know how it works.
> The fact that there is exactly one active default namespace at any
> time is not spelled out in the documentation.
> The packages active in the outer block are *not* active in the inner
> block. The inner block is in the inner package. Were C<package> to do
> what the documentation can be incorrectly read to say it does,
> C<package> would put a namespace at the head of a list of namespaces
> that are to be searched for dynamic symbols. That is not what happens,
> of course, but the current docs can be read to give that idea.
> By changing
>     The package statement declares the compilation unit as being in
> the given namespace.
> to
>     The package statement instructs the compiler as to which namespace
> to look up unqualified dynamic variable and subroutine names in.
> I hope to make it clear that there is exactly one namespace (singular)
> where symbols are looked up in, while avoiding scary jargon (declares
> the compilation unit) that isn't well defined and might not be used
> correctly. Do we use "compilation unit" elsewhere?

I think so.

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

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.

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.

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

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

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. :-)


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About