in reply to Moose again...Debugging?

Note that the module that's being used is MooseX::Types, not "MooseX", which is a namespace containing modules for extending Moose. I believe that only the Moose project itself consumes the "Moose" namespace. This apparently reduces confusion with such an expansive project.

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.

Replies are listed 'Best First'.
Re^2: Moose again...Debugging?
by tj_thompson (Monk) on Dec 18, 2010 at 18:40 UTC

    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.

[reply]
[d/l]

      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

[reply]
      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.

[reply]
[d/l]

        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.

[reply]

        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.

[reply]
[d/l]

In Section Seekers of Perl Wisdom