Perl 5 Porters Weekly: October 22-October 28, 2012
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
Weekly p5p summaries
Hi
I'm always happy to read these summaries, because I don't always grind thru the whole mailing list's messages.
This time it's an especial Three Cheers for Peter Rabbitson.
And not just for his whole complaint, but for this: "auto-deref (which has not yet backfired, but it will)". I told you so, the minute I say the proposal. I admit I do dislike the complexity of say,
my($data) = {stack => [], ...};
push @{$$data{stack} }, $x;
But does it have to be 'fixed'? IMHO the auto-deref is a timebomb. We'll see.
And Peter, the reason for the madness you write about in general (not auto-deref explicitly) is that people in groups do things which those individuals would never do when acting as individuals. This is a sad and hard-won realization eventually achieved by all those who deal with such cases. Witness group activity of /all/ types, political/religious (which includes Communism and Nazism)/etc/etc. It's virtually unheard of for a sensible individual to have the wisdom and power to block such activity :-((.
Cheers
Ron
It's sadly too early for cheers. The only *independent* party who replied to the very core of my complaint was bulk88. That is "why is everyone silent when an obvious trainwreck is being designed". The rest of the massive thread was me parring down the folks blindly supporting a future at any cost.
Basically as the one who started the thread I deem it an utter failure, and a waste of everyone's time. Which is indeed sad :(
Hi Peter
Understand. I replied (I think) to a blog entry on this site.
I see several courses of action:
None. Most likely.
An explicit policy of leaving things as-is. See above.
A decision to eliminate the feature. Preferred.
A compromise. This is my 2nd preferred. It is: Add something like:
So the user forces the option on, and the auditor of the code is warned.
Cheers
Ron