use Perl

• On Warnings (Score:1)

  by chromatic (983)

  [When] the computer can find potential problems -- particularly when it's close to compile time -- this is far better than requiring the programmer to always look for those potential problems.

  This is not a case where the computer can identify problems with certainty. The compiler cannot judge your intent. Did you make a typo in the name of a class-local method such that it collides with the name of a composed method? Did you forget to read the documentation? Did you do it deliberately? Did someone up
  • Re: (Score:2)

    by Ovid (2709)

    Please note that I'm not trying to change your opinion here because it's obvious that we strongly disagree here. I provide this for anyone else who may be reading this.

    This is not a case where the computer can identify problems with certainty. The compiler cannot judge your intent.

    And that's why the warning is so desperately needed. If I inherit from A and B and both provide a "foo" method, I usually get the one that I've inherited from first. One could argue that I forgot to read the documentation or that I did it deliberately, but just like the composition problem I list above, there's no way that the compiler can
    • Re: (Score:1)

      by chromatic (983)

      If you mean "override the method", then this implies I knew the method was there and explicitly excluding it takes about two seconds and let's other developers come along and instantly see that there's an excluded method. This is a benefit because it increases the readability of the code.

      Yet when I override multiple methods (or all of the methods) from a role for the purpose of complete allomorphism or delegation, your approach means that I have to exclude every one of them explicitly, which is mere busy
      • Re: (Score:1)

        by zby (4817)

        Hmm maybe we need some examples here. I am just starting to use Moose, so I must be missing something, but I cannot imagine someone wanting to override all methods of a used role.
        • Re: (Score:2)

          by Ovid (2709)

          I can easily imagine this. If you simply want to say "I provide this behavior" but your implementation differs significantly, you might override all of the roles (this is different from an interface because the role can also provide an implementation). The issue is that this is the use case that chromatic wants to support and I'm against silently discarding behavior.
          • Re:On Warnings (Score:1)

            by zby (4817) on 2009.04.25 6:45 (#68303) Homepage

            I don't understandy why to declare "I provide this behaviour" someone would use a Role. Maybe it comes with more practice - that is why I ask for concrete examples.

            Reply to This

            Parent

            • Re: (Score:2)

              by Ovid (2709)

              Let's say that you can serialize an object as HTML. You might use the role Role::Serializable::HTML with a &serialize method. Then someone can ask:

              if ( $object->DOES('Role::Serializable::HTML') ) {
                  print $object->serialize;
              }

              By providing a name for the behavior, you are guaranteeing to someone that you provide a &serialize method and that it will serialize the object as HTML.

              However, and this is chromatic's concern, it's quite reasonable that the object might want to use that r
            • Re: (Score:1)

              by chromatic (983)

              I've written a lot of mock objects, and I've had to work around a lot of code which performs its own type checking. That can interfere with the work of mock objects. I plan to write an article with more concrete examples soon, but for now I hope it's not too abstract to say that the question "Is this entity a member of an inheritance hierarchy at this point or lower?" is much less interesting and much more difficult than the question "Does this entity perform the behavior I expect?"