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.

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.

I guess I should have made the MooseX::Declare part more obvious, sorry about that. I'm not defining the new method, so it's not a double definition.

I'll play with the -MO=Deparse. What does this do exactly? It's not something I've used before. I do get a message that the syntax is ok.

I guess I should have made the MooseX::Declare part more obvious ...

Honestly, I guessed it from the issue you were having, but yeah specifying that will help others to help you.

Moose is one module and MooseX::Declare is another one entirely with it's own "unique" programming experience. I personally still don't feel that MooseX::Declare is ready for production. A good number of people use it and seem to not have many issues, however a good number of people find it to be touchy and prone to breakages and has horrendous error messages (all of which are being worked on, but are non-trivial tasks).

I would second duelafn's recommendation and switch back to vanilla Moose, you will find that beyond simply syntactic sugar, you are only missing method param validation which can be accomplished (although somewhat less elegantly) will MooseX::Params::Validate.

-stvn

It shows the representation of the code after it's been parsed.

From the B::Deparse documentation:

B::Deparse is a backend module for the Perl compiler that generates perl source code, based on the internal compiled structure that perl itself creates after parsing a program. The output of B::Deparse won't be exactly the same as the original source, since perl doesn't keep track of comments or whitespace, and there isn't a one-to-one correspondence between perl's syntactical constructions and their compiled form, but it will often be close. When you use the -p option, the output also includes parentheses even when they are not required by precedence, which can make it easy to see if perl is parsing your expressions the way you intended.

An explanation on why the O module is used, from a response to "B::Deparse vs. O=Deparse":

B::Deparse loads functions to deparse Perl code. But since you never use the module, it's rather useless to load the module.

O, on the other hand, behaves very specially when loaded. It loads the program, dumps it using the specified dumper (e.g B::Deparse), and prevents it from executing as if -c had been specified.

$ perl -MO=Deparse,-p -e" die warn print "
die(warn(print($_)));
-e syntax OK
[download]

You were spot on with the MO=Deparse recommendation. Since you all took the time to help me out, I'd like to mention that I resolved this issue (finally!) and figured out the issue.

As it turns out, in my Program::Plist::Pl package, I use Program::Types qw(Pattern) This results in importing a subroutine into my package with the same fully qualified name as my Program::Plist::Pl::Pattern package. The result is that when I was saying Program::Plist::Pl::Pattern->new I thought I was saying 'Program::Plist::Pl::Pattern'->new(). However, I was really saying &Program::Plist::Pl::Pattern()->new(). And that's how I was ending up off in MooseX::Types land instead of inside my constructor.