Here's the relevant portion of MooseX::Types::TypeDecorator, version "0.25", downloaded a few minutes ago off of CPAN, via the source link. I'd added a comment to mark line 89.
sub new { my $class = shift @_; if(my $arg = shift @_) { if(blessed $arg && $arg->isa('Moose::Meta::TypeConstraint')) { return bless {'__type_constraint'=>$arg}, $class; } elsif( blessed $arg && $arg->isa('MooseX::Types::UndefinedType') ) { ## stub in case we'll need to handle these types different +ly return bless {'__type_constraint'=>$arg}, $class; } elsif(blessed $arg) { __PACKAGE__->_throw_error("Argument must be ->isa('Moose:: +Meta::TypeConstraint') or ->isa('MooseX::Types::UndefinedType'), not +". blessed $arg); } else { __PACKAGE__->_throw_error("Argument cannot be '$arg'"); } # line 89 } else { __PACKAGE__->_throw_error("This method [new] requires a single + argument."); } }
MooseX::Types says <q>MooseX::Types uses MooseX::Types::TypeDecorator to do some overloading which generally allows you to easily create union types. As with parameterized constrains, this overloading extends to modules using the types you define in a type library.</q> This leads me to believe this could be evoked from all sorts of attribute-defining code.
It would help to show us line 74 of PI.pm, where _create_pattern_obj is apparently evoking an invocation of this type decorator stuff. I'm not familiar with MooseX::Types at all, so I don't know what using it would look like, though I have played with Moose a little.
In reply to Re: Moose again...Debugging?
by Anonymous Monk
in thread Moose again...Debugging?
by tj_thompson
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |