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 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 for everyone (read: mostly beginner and intermediate users), and then enable more complex features to expert users. "strict" for example, should be on by default and users that prefer to do "no strict 'refs'" could.

        Strict isn't on by default because of wrong design much earlier on, Modern::Perl helps fix that.

        Of course, these are only my 2 cents, at least right now. I hope I'm not stepping out of line here.

        • You're not stepping out of line at all. I think everyone who has thoughts on these matters should feel free to chip in.

        • 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
            • One thing which might help is that I just uploaded MooseX::Role::Strict [cpan.org] (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.