Front page | perl.perl5.porters |
Postings from July 2012
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=113974Thread Previous | Thread Next