Welcome to Perl 5 Porters Weekly, a summary of the email traffic of the
perl5-porters email list. I’d hoped to get this published earlier, but
it didn’t happen.
In the US, we just switched back to “standard” time on Saturday. Rah, rah
energy savings, but toddlers don’t adapt well to legalistic time changes, so
I was up and at ‘em at the butt crack of dawn this morning.
Enough complaining, let’s get to this week’s topics. I hope you wanted a
week full of discussion(?) around subroutine signatures, because that’s what
we got.
- perl-5.16.2-RC1 is now available
- 5.12.5 last call for patches
- Consider Forbidding Developer Releases in Production Perls
- No-taint support in Perl
- What happened to the whole “small core” idea?
- sub signatures
- too many arguments
- function to return the signature
- too few arguments
- status – I’m going quiet for a while …
perl-5.16.2-RC1 is now available
Ricardo Signes announced that perl-5.16.2-RC1 is now available at CPAN
mirror near you.
5.12.5 last call for patches
Dominic Hargreaves is asking for any patches that should be applied to a new
5.12.5 maintenance release.
Consider Forbidding Developer Releases in Production Perls
Jeffrey Thalhammer (author of Perl Critic and Pinto among others), and
Miyagawa (author of Plack among others) were bitten by a problem that came
about because 5.16.x ships with a development version of EU::MakeMaker. So
he proposed that production releases ship only with production versions of
any modules.
No-taint support in Perl
In our last episode, Steffen Mueller proposed a compile time option to
disable taint checking and this week Ricardo Signes (our current pumpking)
wrote that it seemed “potentially useful.
What happened to the whole “small core” idea
Peter Rabbitson posted a lengthy email asking whatever happened to the
“small core” ideals promoted by Jesse Vincent, the previous pumpking. He
writes:
I will start with the TL;DR - I can not fathom why given Perl's
*exceptional* modularization track record, the general tendency on p5p
still is "MOAR CORE FEATURES!!!". I also do not understand how does this
sentiment continue to survive given an overwhelming mass of core devs
opposing such experiments (I do substantiate this claim - keep reading).
The whole email is worth reading, and there were several thoughtful replies,
although Ricardo’s reply came on October 29, just after the cutoff for this
summary.
subroutine signatures
Peter Martini checks in with a status update on his subroutine signature
work, including some discussions around behavior when too few or too many
arguments are provided, how to programmatically get the expected parameter
list, and finally a promise to continue working on things given all of the
feedback.
He writes:
I think I'll stop stoking the fires til I clear off the work on my plate,
which includes:
* Make a new branch to I can create a new series of commits cleanly
* The code cleanups Father C posted.
* Remove the @_ ban (I'll commit it and immediately revert it in the new
branch, so it can be easily added back)
*** In the commit adding it, I'll ban goto from a sub with a signature, so
there'll be record of that.
** Strict parameter count checking*. sub foo($bar) requires exactly one
parameter. sub foo(@bar) or sub foo(%bar) requires 0 or more, and will
die/croak otherwise
* Make goto &foo work
* Make the signature parameter in the padlist an AV* instead of an int
(mainly future proofing)
* Rename the proto attribute to prototype (Father C prefers prototype, and
I don't recall anyone else having a preference one way or another)
* attributes.pm/xs should be aware of the prototype attribute (but I think
it should only be aware of it enough to say use : prototype() directly)
* Change the name of the feature to just 'signatures' (but flagged as
experimental)
* Make sure all tests pass at each commit
Thread about too many arguments
Thread about too few arguments