Front page | perl.perl5.porters |
Postings from October 2012
On Sat, 2012-10-27 at 01:41 +1100, Peter Rabbitson wrote: > Let's focus on sub signatures for a bit. I've read every thread about > them. Peter Martin's work kicks ass. The speedups are tangible which is > even more awesome. Yet the whole proposal seems to be set up “It either > happens in core or it doesn't happen at all”. Why? What prevents the > core from exposing the correct-level hooks, have *these* hooks unit > tested, and relegate the syntax extension mucking to CPAN? I do not > think performance is an issue – after all linked C is linked C. > Maintainability can't be a problem either – if anything it will be > awesome to have a well factored boundary that will make a performant > CPAN module for such extensions possible. Perhaps testing, but with > CPAN-wide smoking the way we do today, this *also* isn't a problem. For me, it's because at one point I'd also like to be able to use these features in pure-perl modules. > Furthermore, and this is what baffles me most – I do not seem to be > alone in this sentiment. I am a long-time p5p observer. I do not > participate in p5p dev directly, and even temporarily stepped away from > CPAN this past year. Yet I still go to conferences and meet people, some > of them prominent p5p figures. An overwhelming majority of these folks > flat out stated in a private conversation that adding more syntax to > Perl 5 is not the way to go. Even some members of the Moose cabal have > agreed with me in private that having compile-time acting signatures > prototyped on CPAN first is the sane way forward. Yet when something of > such magnitude is brought up to the list, the general response from > these *same* folks is <crickets>. Furthermore if one reads more into the > threads gems like the following pop up: But this feature has been prototyped on CPAN in various forms. > Perl5 just turned 18 a week ago (according to a0d0e21ea6e). It is now > legal to express ones love to this great dynamic language in every way > possible. What better time to ask where is Perl5 going and why can't it > stay Perl5? I completely disagree that new features mean it isn't Perl 5 anymore. We didn't need //, but I'm really happy it's there. Don't get me wrong, I'd personally rather have fail-on-missing-params and fail-on-too-many-params as default behavior, but since the current proposal is precisely just what most CPAN prototypes have in common, I would see no problem advertising this features for people to clean up their code. regards, -- Robert 'phaylon' Sedlacek Perl 5 Consultant for Shadowcat Systems Limited - http://shadowcat.co.uk/Thread Previous | Thread Next