Welcome to this week’s Perl 5 Porters summary. By the time you’re reading this, I’m probably at OSCON, so if you’re in Portland too, please come to my talk “Introduction to Git for the Perl Hacker” Wednesday 2:30 pm (PDT), or let’s meet up and have a beer. (Contact)
Topics this week include:
- Modernize perlopentut.pod
- Build warnings in 5.12.x
- float operations
- package NAMESPACE manpage comments
- given should localize topic, not lexicalize topic
- my() with empty list causes weird error
Modernize perlopentut.pod
This thread started off innocently enough, but devolved into a shouting match. If you need a refresher, perlopentut is intended to be a friendly introduction to the various ways Perl handles open(). Many in the thread want perlopentut to feature the 3 argument open style instead of the two argument style that it leads off with right now. After some ruffled feathers, the ticket was closed until a new patch is written.
Build warnings in 5.12.x
Responding to an RT ticket about build warnings in 5.12, Jesse Luehrs asked if P5P was considering a 5.12.5 release. Ricardo Signes (our current pumpking) replied yes, it is being considered.
float operations
Some of the PDL folks posted a question about why there’s a variance between Perl’s computations for NaN (not a number) and infinity values and ones computed from C. There was some discussion about making a test suite for this (as it seems some values and their signedness changed in various perl releases.)
package NAMESPACE manpage comments
A very popular thread this past week focused on the meaning of the “our” and “use vars” declarations. I think Rik summed up the behavior succinctly:
"use vars" means "mark these variables as imported, even though they are not."
If you "use vars '$x'" in package Foo, then anywhere that you switch into
package Foo, $x will mean $Foo::x (unless it has been shadowed by a lexial
name).
In no case does this $x become a superglobal, available without qualification
everywhere. It's always accessible as $Foo::x, sometimes as $x, and that's
that.
"our" variables are available by short name in the enclosing lexical scope.
"use vars" variables are available by short name whenever in the importing
package.given should localize topic, not lexicalize topic
It looks like Rik has made a decision about the proper behavior of given’s treatment of the topic variable ($_) and the decision is given should treat $_ as an implicit local instead of implicit my. That’s kind of a big deal.
my() with empty list causes weird error
Seems like this thread is heading toward a resolution. Rik initially replied that he didn’t think allowing my() was a good idea, but he changed his mind after reading this rationale from Aristotle Pagaltzis:
[W]hat of the following?
$ perl -E'say for \($x,$y)'
SCALAR(0x8078654)
SCALAR(0x80786f4)
$ perl -E'say for \my ($x,$y)'
SCALAR(0x8078650)
SCALAR(0x8078678)
$ perl -E'say for \()'
$ perl -E'say for \my ()'
Can't declare stub in "my" at -e line 1, at EOF
Execution of -e aborted due to compilation errors.
Why would the last example here be the odd one out? What makes an empty
list so abhorrent in the vicinity of `my` that unlike anywhere else in
Perl, there it has to be forbidden?Rik responded:
I cede that "my ();" might as well be fixed. Those who would hate to see it in
their code can write a linter plugin. 