| Subject: | Errors using type constraints in Args |
I was looking forward to using type constraints in Args with this new release, but I keep stumbling across the same error message. Following the examples in the Route Matching pod, doing this:
sub item : Chained('base') PathPart('item') GET Args('Int') {
my ( $self, $c, $item ) = @_;
....
}
results in this error message:
'Int' not a type constraint in /item at /home/autumn/perl5/lib/perl5/Catalyst/Action.pm line 246.
Trying the same method using Types::Standard without quoting the type, as per the documentation, produces the same error. Trying it with multiple type constraints, as per the docs, also turns up a similar error message:
'Int,Int,Str' not a type constraint in /item at /home/autumn/perl5/lib/perl5/Catalyst/Action.pm line 246.
I tried this in two of my Catalyst projects, both with the same result. Thinking the problem might have something to do with other parts of my code, I created a brand-new Catalyst project for testing, using the helper script, and copy-pasted two examples from the docs into the Root controller:
sub find :Path('') Args('Int') {
my ($self, $c, $int) = @_;
}
and
use Types::Standard qw/Int Str/;
sub find :Path('') Args(Int,Int,Str) {
my ($self, $c, $int1, $int2, $str) = @_;
}
I still get the same error messages with both. This happens with Args and CaptureArgs.
I'm far from being a Perl guru, so looking at line 246 of Catalyst::Action, in the resolve_type_constraint method, I'm not sure what's going on there enough to know where the problem lies.
my @tc = eval "package ${\$self->class}; $name" or die "'$name' not a type constraint in ${\$self->private_path}";
I've never seen eval used with "package" and can't find any explanation of what it does with a Google search (and only a few examples using grep.cpan.me), so I may be reading this wrong. It seems to be testing whether both the referring package exists and that $name isn't empty? The die message though seems to indicate that it's testing whether $name is a valid type constraint, but I don't see it actually doing that. $name obviously exists, as it's being returned in the error message, so I'm assuming the package statement is causing the issue?
Also, since using multiple constraint arguments results in 'Int,Int,Str' as $name, the die message appears to be even more confusing, as 'Int,Int,Str' would certainly never be a valid type constraint.
I'm using Perl 5.20.1 on Linux kernel 3.16.7, openSUSE 13.2 x86_64.