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:2)

        by Ovid (2709)

        For the case of overriding everything or almost everything and the role is not simply an interface, then yes, the work to exclude all of the role's methods would be annoying. That's the only interesting argument I've heard from this entire discussion and had the discussion started out with this, then things might have gone easier.

        The problem is that your solution is still throwing away information, my solution can be cumbersome at times. So the reality is that this is a syntax issue. If a good, clean syn
        • Re:On Warnings (Score:1)

          by chromatic (983) on 2009.04.25 15:04 (#68308) Homepage Journal

          If a good, clean syntax were found which makes overriding a role's methods explicit and non-cumbersome but still warns about ambiguity, then both concerns can be addressed.

          mst has some very nice examples using MooseX::Declare, where you provide a block after applying a role. Any method you define in that block very obviously takes precedence over methods composed from the role.

          ... your solution of ignoring the real, existing, many hours of debugging problem that we've had at the BBC trying to find those silently overridden methods doesn't work for me.

          I'm not ignoring it. I've consistently said that an on-by-default warning is the wrong approach. An optional warning is just fine. Make one, use one, enforce it in your coding standards -- great! You should have that option. Sometimes I may use that option too.

          You know how you use roles. My concern is how everyone uses roles and what the design of Moose roles promotes and discourages.

          Reply to This

          Parent