Bug #131720 for Type-Tiny: slurpy parameters don't work with Type::Params::compile

Sun Feb 09 17:22:35 2020 violapiratejunky [...] gmail.com - Ticket created

Subject:

slurpy parameters don't work with Type::Params::compile_named

Adding slurpy to compile_named throws this error: Expected parameter name as string, got HASH(0x5584694d6428) I think I am using it as specified in the documentation: test_slurpy(message => "hello!", 123); sub test_slurpy { state $check = compile_named( {named_to_list => 1}, message => Str, slurpy ArrayRef, ); my ($message, @slurped) = $check->(@_); say "$message"; }

Tue Feb 11 13:17:27 2020 perl [...] toby.ink - Correspondence added

This is currently documented incorrectly. Slurpies for a function with named parameters are still expected to be key-value pairs. So it's more like: sub test_slurpy { state $check = compile_named( message => Str, options => slurpy HashRef, ); my ($got) = $check->(@_); use Data::Dumper; print Dumper($got); } test_slurpy( message => "Hello world", colour => "blue", size => 24 ); # $VAR1 = { # 'message' => 'Hello world', # 'options' => { # 'size' => 24, # 'colour' => 'blue' # } # }; # So "options" acts like a named parameter that slurps up all the other named parameters.

Tue Feb 11 13:17:27 2020 The RT System itself - Status changed from 'new' to 'open'

Wed Feb 12 23:50:33 2020 violapiratejunky [...] gmail.com - Correspondence added

Ah, thanks for the explanation. I assume having Array slurpies at the end is challenging? Or is it that you think it doesn't make sense when using named parameters? On Tue Feb 11 13:17:27 2020, TOBYINK wrote: Show quoted text

> This is currently documented incorrectly. > > Slurpies for a function with named parameters are still expected to be > key-value pairs. So it's more like: > > sub test_slurpy { > state $check = compile_named( > message => Str, > options => slurpy HashRef, > ); > > my ($got) = $check->(@_); > > use Data::Dumper; > print Dumper($got); > } > > test_slurpy( message => "Hello world", colour => "blue", size => 24 ); > > # $VAR1 = { > # 'message' => 'Hello world', > # 'options' => { > # 'size' => 24, > # 'colour' => 'blue' > # } > # }; > # > > So "options" acts like a named parameter that slurps up all the other > named parameters.

Thu Feb 13 05:25:40 2020 perl [...] toby.ink - Correspondence added

It becomes hard to recognize where the named parameters end and the slurpy ones begin. Like if you had a named Optional[Str] parameter "foo" followed by a slurpy array of strings, how do you tell the difference between these? my @strings = qw(x y z); myfunction( foo => "bar", @strings ); my @strings = qw( foo bar x y z ); myfunction( @strings ); It becomes too ambiguous. Sometimes your needs are going to be too complex for Type::Params to handle, and I'm okay with that. Types::Standard still gives you the tools you need to check data types after you've manually unpacked @_. sub myfunc { my $foo; if ($_[0] eq 'foo') { $foo = Str->($_[1]); splice @_, 0, 2; } my @strings = map Str->($_), @_; ...; }

Wed Feb 19 15:40:04 2020 perl [...] toby.ink - Correspondence added

Documented in 1.010000.

Wed Feb 19 15:40:04 2020 perl [...] toby.ink - Status changed from 'open' to 'resolved'

Wed Feb 19 16:00:29 2020 violapiratejunky [...] gmail.com - Correspondence added

On Wed Feb 19 15:40:04 2020, TOBYINK wrote: Show quoted text

> Documented in 1.010000.

That all makes sense. Thanks for the explanation and documentation!

Bug #131720 for Type-Tiny: slurpy parameters don't work with Type::Params::compile_named