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

[perl #113974] package NAMESPACE manpage comments

Thread Previous | Thread Next
From:
Father Chrysostomos via RT
Date:
July 6, 2012 12:38
Subject:
[perl #113974] package NAMESPACE manpage comments
Message ID:
rt-3.6.HEAD-28836-1341603477-1781.113974-15-0@perl.org
On Fri Jul 06 09:16:44 2012, demerphq wrote:
> I think that a lot of the confusion in this discussion comes from the
> fact that optimizations and bugs have broken the original model for
> global namespaces.
> 
> Consider Eric example. He is of the view that it shows something. I am
> of the view that what it shows is a bug in the implementation. "our"
> was introduced a replacement for "use vars" therefore I would expect
> it to behave the same, but it doesn't. I would contend that this is a
> bug.
> 
> Recently Zefram and I debated the behavior of subs hard binding to a
> SPECIFIC global as an optimization, which in turn breaks code that
> uses those variables and the stash has been deleted and replaced. IOW,
> the late binding of the variable to the stash has in the name of
> optimizations been converted to an early binding, almost as though the
> code was bound to a lexically allocated var.

That optimisation has been there since perl 1.  So ever since stash
manipulation was added (perl 5, I think), it has behaved the way it
currently does.

> To me a global variable is syntactic sugar for writing a fully
> qualified stash lookup, and I am confident that is the meaning Larry
> had in mind at the beginning. You can vestigates of this that you can
> localize a package level scalar but not a lexically scoped scalar, but
> you can localize a hash value, or array value regardless.
> 
> So then over time optimizations without proper analysis and tests have
> broken some of this, leaving the actual state of play unclear.
> 
> I would welcome a definition of these two types of variable that does
> not in any way rely on implementation.

Sometimes the implementation does count.  In the case of $var binding to
*var at compile-time, changing that would break hundreds of CPAN modules.

> When I say that "our" doesnt create anything what I mean is that the
> kind of creation that happens is only tenously related to the our.

Even the confusion it creates? :-)

> If
> any symbol of the same name already exists in the same namespace then
> "our" is basically a compiler hint. If the symbol doesnt exist then
> the our does create something, but indirectly, via a mechanism that is
> used by many codepaths.
> 
> I personally will not accept any argument that is based on the current
> broken behavior of our as I consider the behavior of the following
> code to be plain and simply a bug.

Please read
<http://www.nntp.perl.org/group/perl.perl5.porters/;msgid=200001140034.QAA13711@kiev.wall.org>.

> package Foo;
> use vars qw($FOO);
> $FOO="FOO";
> 
> package Bar;
> print $FOO;
> 
> package Baz;
> our $BAZ;
> 
> $BAZ= "BAZ";
> 
> package Bop;
> 
> print $BAZ;
> __END__
> BAZ
> 
> Yves


-- 

Father Chrysostomos


---
via perlbug:  queue: perl5 status: open
https://rt.perl.org:443/rt3/Ticket/Display.html?id=113974

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