Slash Boxes
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.
More | Login | Reply
Loading... please wait.
  • I would prefer to have warnings for possible problems that you would only run into by accident. If you would not want that to happen, you could just declare so.

    What's Rolsky's position on the subject, If I may ask?

    • I don't know how Dave feels, but Stevan Little has already said "no". He prefers new features to be tested in a MooseX:: class and that makes sense to me.

      • 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.

        We should work on making these easy to use fo

        • 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 u

          • 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
            • Perhaps this is possible?

              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