All the Perl that's Practical to Extract and Report

Navigation

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Without JavaScript enabled, you might want to
use the classic discussion system instead. If you login, you can remember this preference.

We always return to the same issue though, of whether new users should have to explicitly declare features which make it easier to use, instead of experts explicitly expressing to ignore different warnings.

Moose has become a stepping stone in an Enlightened Perl and any Enlightened programming language, and users should not be bitten by these simple things. Also, users should not (by design), have to know about various MooseX modules to fix the behavior for them.

The difference, and this is the important one here, strict enables warnings about features in Perl that we actively want to discourage, Symbolic references, global variables, undeclared barewords. The Role warning specifically is triggered on valid and more importantly encouraged use cases.

There's an idiom of role usage where you define a default implementation of a method and then override that in classes where you need a more specific version of it. You may recognize this, it's one of the reasons people use Multiple Inheritance. Having this use case warn unless you specifically exclude a role penalizes it and subtly implies that it's not a valid idiom.

If that were the end of the story I'd probably say "fork Moose" and be happy to have more competition. But that's not the end of the story. Perl::Critic handles cases where it may be against local Best Practice to use what would be otherwise valid and encouraged code. I sort of feel that Ovid is being unfair saying that "people who don't want action at a distance are being penalized" because Shawn Moore has started enabling [blogspot.com] new critic tests to deal with exactly this case.

As for enabling features in the MooseX:: namespace. This has always been the encouraged method of adding new features to Moose. Things that get vetted in MooseX:: will eventually get folded back into Moose:: and possibly Moose core. The current best prospects for this is MooseX::Types, MooseX::AttributeHelpers, and MooseX::Storage which are three of the oldest MooseX:: packages out there.

First I want to thank you for taking the time/effort to inform me more about this. Sorry for the late response.

Secondly, there are still two issues that make me ponder:

What about beginners who have their methods overridden without knowing? I'm not saying that warning everyone is the only solution, I just know this is an issue we should think of, because it's more important, IMHO.

I wish I could say that most beginners don't use Perl::Critic, but unfortunately the case is that most programmers don't use P

It's possible, but I believe it's inadvisable. It's not the role's business how anyone else wants to perform the role. Any role which dictates how people perform the role (composition, inheritance, delegation, allomorphism) is not a role anymore.

Sure it's OK. The role isn't telling any class how to perform that role. It's just providing a way of meeting a need that you apparently don't have. Your objection was that by adding the warning, it forced programmers to use clumsy ways of getting around the fact that you might want to use a role as an interface or primarily as an interface. By combining strict roles and 'includes', some of the difficulty goes away. For example:

package My::Class;use Moose;# or whatever the final syntax is, if accepted

Strict roles reintroduce one of the problems that I always intended roles to solve: enforcing implementation details at the worst possible place, where you know the least about how people will actually use them.

Let me put it this way. I believe that allowing the creator of a role to specify that you must use inheritance or delegation or allomorphism or reimplementation to satisfy the demands of the role is like allowing the creator of a class to say that you cannot inherit from it. The real responsibility

To be fair, there's one category of behavior where it's acceptable for the creator of a role to enforce a usage strategy: where the role only requires the presence of other methods without providing implementations. Note, however, that even that case does not dictate how the composing class provides those methods.