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 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 [] 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
            • One thing which might help is that I just uploaded MooseX::Role::Strict [] (it will be a bit before that link is good). Hopefully that will help people who are concerned about this.

              Now I'm looking into adding includes into Moose.

            • 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

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

                  • I apologize. You have offered a solution and just because I'm so frustrated with this discussion, I've mischaracterized your position. I'm sorry about that and I certainly didn't mean to.