Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I really think that doing anything that is equivalent the following is an incorrect usage of the feature more then it is a bug.

    Some::Role->meta->apply($object) while 1;

    You can simply modify this line slightly and avoid all your warnings by doing this ...

    while (1) {
        Some::Role->meta->apply($object) unless $object->does('Some::Role');
    }

    Sure it would be nice if Moose prevented you from shooting yourself in the foot like this, but what if you really wanted to shoot yourself in the foot? Who is Moose to say you can't? I think this type of thing is more a case of "your probably doing something stupid, but in case your not, and it is actually something clever, we will allow it" then it is a case of "your doing something stupid and we wont let you".

    This problem is closely related to the "ordering problem" with mixins and multiple inheritance that roles were designed to avoid!

    Yes, this is true, but that is because you are re-applying the role at different times. The ordering problem is only solved when you apply all your roles at once and they can be merged. For instance ..

    package Foo;
    with 'Bar', 'Baz';

    ... is not the same as ...

    package Foo;
    with 'Bar';
    with 'Baz';

    They can potentially create two very different classes because the former merges the Bar and Baz roles first (doing all the conflict detection and role merging goodness), whereas the later will first apply the Bar role, then apply the Baz role and not do any conflict detection between the two roles.

    - Stevan

    • I do see your point and I think you're right (I've some issues with implementation, but that's OK :). At the very least, though, I would like to see Moose::Role be able to generate a sane error message to make it easier to track bugs like this down.

      • The problem is that we are not considering it an error. The particular errors you were getting were tricky not because of something Moose::Role did as much as your repeated application of the role to the class caused really odd side effects to happen. How would I tell the difference between a error borne from side-effects and one that I could directly trace back to a mis-use of the feature?

        - Stevan

        • I'm not saying that Moose::Role is behaving in error here. I'm saying there's a detectable error condition and a better error message would help.

          How would I tell the difference between a error borne from side-effects and one that I could directly trace back to a mis-use of the feature?

          When applying a role at runtime, by noting Perl's recursive inheritance limit (98 role applications on my Solaris box) and issuing a reasonable error reporting the package/file/line number of role application, it would have been trivial for me to find the source error. Currently this error wins my personal "most obscure error message" award :)

          Deep recursion on s

          • Okay, I will agree that is could be detected, but how simple it is to do is another thing entirely. You are always invited to fork the Moose git repo and patch this if you like.

            - Stevan