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.");        
    }
}
[download]

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.

Yeah, I checked out that code as well. Didn't tell me much unfortunately, other than it appears to expect a TypeConstraint object and wasn't finding it which was confirmed by the additional debug output I put in. I'd like to know where it was being called from so I could trace the problem back, but it's not on the call stack.

Here's the relevent code:

  method _create_pattern_obj (Str :$name, Maybe[Str] :$mask_data, Mayb
+e[Str] :$tag_data) {

    my $tags = {};
    map {$tags->{$_} = 1;} split(',', $tag_data) if defined $tag_data;

    my $pattern_obj = Program::Plist::Pl::Pattern->new(name => $name,
                                                       mask_data => $m
+ask_data,
                                                       tags => $tags);

    $self->_add_pattern($pattern_obj);
  }
[download]

The relevant line throwing the error is the call to Program::Plist::Pl::Pattern->new.

After many attempts at using MooseX::Declare, I gave up and moved everything to vanilla Moose. I had hoped that after learning the basics the huge errors would make sense or be significantly less frequent but I was unable to reach that point. From my experiences, I personally think that MooseX::Declare (and Method::Signatures) is just over the edge of too magical.

Good Day,
    Dean

Oh, you're using MooseX::Declare! Yeah, that'll make debugging like poking a lunar rover.

My first thought is to run the program with the argument -MO=Deparse and see if the generated code is of any help. I guess you'd have to find where the right ::TypeDecorator object is created and what's going wrong there. This will likely take some time, and there will be a lot of indirection, but it's taking the mystery meat syntax out of the equation.

I keep thinking about ::Pattern's constructor, and I have to remind myself that Moose is providing that, so it's unlikely that you have a bad method signature that doesn't allow that argument (but usually bad args have more obvious error messages in MooseX::Delare, in my experience). Although, if new is inadvertantly defined, maybe that's part of the problem.