On Sun, 2012-10-28 at 06:43 +1100, Peter Rabbitson wrote: > This is an interesting stance to take... I fail to see the appeal of > pure-perl to establishments where upgrading perl is not an issue. I can > not think of a situation where one can expect a recent perl while at the > same time not having access to XS. Please tell me what am I missing. Fatpacking, or sending any kind of code over the wire to be run somewhere else. The dependency might be small in itself, but turning a whole dist CPAN dependent for that is a trade-off. > It has not, see my reply to Aristotle, which should show up within an hour. As someone who wrote some of the signature code on CPAN, and did a lot of prototyping that was never released, I disagree. If we start out requiring that language-inclusion changes are *fully* tested on CPAN, you'd need to make any decision on the language level flexible to be manipulated. Just like with the @_ thing. Every way to change that, make it (not) available, magical and so on has to be provided in core without even knowing if it's worthwile. So I think the line needs to be drawn somewhere. That said, there has been lots of talk between developers doing signatures about @_, but only if it should contain only the rest or all of the arguments, if methods should contain the invocant and so on. But the main fact is, I've seen people all around the developer sphere asking for this feature for various reasons. Some so you can have your editor get at your arguments, but many just because they want a single place their eyes can jump to to find the signature of a function. regards, -- Robert 'phaylon' Sedlacek Perl 5 Consultant for Shadowcat Systems Limited - http://shadowcat.co.uk/Thread Previous | Thread Next