Skip Menu |

This queue is for tickets about the Function-Parameters CPAN distribution.

Report information
The Basics
Id: 81177
Status: rejected
Priority: 0/
Queue: Function-Parameters

People
Owner: Nobody in particular
Requestors: perl [...] toby.ink
Cc:
AdminCc:

Bug Information
Severity: Wishlist
Broken in: (no value)
Fixed in: (no value)



Subject: Multiple variables in "shift"
Another wishlist item... Say, for Catalyst handlers, which rather than just being invoked on $self, also always have their next parameter as the context object $c. use Function::Parameters handler => { name => 'required', shift => [qw( $self $c )], check_argument_count => 1, };
Subject: Re: [rt.cpan.org #81177] Multiple variables in "shift"
Date: Fri, 16 Nov 2012 14:07:14 +0100
To: bug-Function-Parameters [...] rt.cpan.org
From: Lukas Mai <l.mai [...] web.de>
On 14.11.2012 22:23, Toby Inkster via RT wrote: Show quoted text
> Say, for Catalyst handlers, which rather than just being invoked on > $self, also always have their next parameter as the context object $c. > > use Function::Parameters handler => { > name => 'required', > shift => [qw( $self $c )], > check_argument_count => 1, > };
I'm very reluctant to add this feature. It's too much magic. By implicitly declaring variables you can no longer see where a variable was introduced and what its scope is. I'm willing to make an exception for $self in methods because it's so ubiquitous and everyone recognizes the idiom. But even the ability to rename $self provided by the 'shift' feature is of dubious worth. I implemented it because $self makes no sense in class methods, so you want something like $class there. But then you need a different keyword, and there's nothing as universally recognized as 'method' is. So this feature would let you create a custom keyword that (hopefully) makes sense for your application. (This was all before the $invocant: feature was added.) Wouldn't 'method foo($c) { ... }' work just as well?