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.
  • If Moose developers won't change the default behaviour (I don't know the issues well enough to argue either way) then I'd hope they'd be open to providing a mechanism to let you do it yourself.

    Perhaps you already can by sub-classing Moose::Role.

    • I'm pretty sure I can subclass Moose::Role, but I've never tried. Sounds like the way to go.

      And at this point, even if they did agree this behavior is wrong (I don't believe they do), this has been part of the interface long enough that I doubt they would change it (kind of like how Perl 5's SUPER:: bug has never been fixed).

      • Note I am not pretending to even play a Moose core developer on TV. I'm just giving my two cents being an active part of the Moose developer community.

        If it was decided that this was the right decision it would be changed with a long deprecation cycle. The Moose team isn't above deprecating bad features. However something like this would need to be "proven" in a MooseX:: class for a while I would think.

        The right answer I think would be to override the Moose::Meta::Role::Application::ToClass class to add the

      • Okay, after much discussion on #moose (soon to be summarized on the mailing list) we will be adding a warning so that when a class method silently overrides the role method it will warn you that this is happening. In order to silence the warning you will have to explictly exclude the method from the role (see Moose::Cookbook::Roles::Recipe2 [cpan.org] for information on this feature).

        For more details, watch for my summary mail on the mailing list.

        - Stevan