Skip Menu |

This queue is for tickets about the Params-Validate CPAN distribution.

Report information
The Basics
Id: 26018
Status: rejected
Priority: 0/
Queue: Params-Validate

People
Owner: Nobody in particular
Requestors: DON [...] cpan.org
Cc:
AdminCc:

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



Subject: RFE: Combine multiply specifed keys into array ref
It would be useful to be able to do something like the following: sub bleh { my %param = validate_with (params => \@_, spec => { foo => {type => SCALAR|ARRAYREF, allow_multiple => 1, } }); } then bleh (foo => 1, foo => 2); would mean my %param = (foo => [1,2]);
On Sun Apr 01 01:40:49 2007, DON wrote: Show quoted text
> It would be useful to be able to do something like the following: > > sub bleh { > my %param = validate_with (params => \@_, > spec => { foo => {type => SCALAR|ARRAYREF, > allow_multiple => 1, > } > }); > } > > then bleh (foo => 1, foo => 2);
Well, Params::Validate is really built around the assumption that @_ contains either a hash or a hash reference. What you're proposing only makes sense with arrays.
On Sun Apr 01 09:58:10 2007, DROLSKY wrote: Show quoted text
> On Sun Apr 01 01:40:49 2007, DON wrote:
> > It would be useful to be able to do something like the following: > > > > sub bleh { > > my %param = validate_with (params => \@_, > > spec => { foo => {type => SCALAR|ARRAYREF, > > allow_multiple => 1, > > } > > }); > > } > > > > then bleh (foo => 1, foo => 2);
> > Well, Params::Validate is really built around the assumption that @_ > contains either a hash or a hash reference. What you're proposing only > makes sense with arrays.
Which is what @_ is; it definetly shouldn't be the default, though.
On Sun Apr 01 15:57:28 2007, DON wrote: Show quoted text
> On Sun Apr 01 09:58:10 2007, DROLSKY wrote:
> > On Sun Apr 01 01:40:49 2007, DON wrote:
> > > It would be useful to be able to do something like the following: > > > > > > sub bleh { > > > my %param = validate_with (params => \@_, > > > spec => { foo => {type => SCALAR|ARRAYREF, > > > allow_multiple => 1, > > > } > > > }); > > > } > > > > > > then bleh (foo => 1, foo => 2);
> > > > Well, Params::Validate is really built around the assumption that @_ > > contains either a hash or a hash reference. What you're proposing only > > makes sense with arrays.
> > Which is what @_ is; it definetly shouldn't be the default, though.
While @_ is an array, when people pass named parameters in they generally think of it as a hash. Honestly, I don't think this is a good idea at all, and I don't think P::V should support it.
From: DON [...] cpan.org
On Fri Apr 06 07:17:44 2007, DROLSKY wrote: Show quoted text
> On Sun Apr 01 15:57:28 2007, DON wrote:
> > On Sun Apr 01 09:58:10 2007, DROLSKY wrote:
> > > On Sun Apr 01 01:40:49 2007, DON wrote:
> > > > It would be useful to be able to do something like the following: > > > > > > > > sub bleh { > > > > my %param = validate_with (params => \@_, > > > > spec => { foo => {type => SCALAR|ARRAYREF, > > > > allow_multiple => 1, > > > > } > > > > }); > > > > } > > > > > > > > then bleh (foo => 1, foo => 2);
> > > > > > Well, Params::Validate is really built around the assumption that @_ > > > contains either a hash or a hash reference. What you're proposing only > > > makes sense with arrays.
> > > > Which is what @_ is; it definetly shouldn't be the default, though.
> > While @_ is an array, when people pass named parameters in they > generally think of it as a hash. Honestly, I don't think this is a good > idea at all, and I don't think P::V should support it.
I definetly agree it shouldn't be the default, but I was hoping to not have to wrap the few cases where it's a good idea (SOAP calls, FE, which don't handle arrayrefs particularly well) with a call which compacted @_ first before calling validate_with. 'course, considering that I have been using P::V for quite a while and this is the first time that I've actually wanted something like this could be a valid reason for not putting it in P::V itself.
I'm no longer going to make any non-bugfix changes to P::V so I'm closing old wishlist tickets.