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 btilly (5037)

        Tell me with a straight face that it's not crazy to apply a role to a class and then immediately list all of the methods you don't want to compose from the role into the class because they appear in the class immediately after the role application.

        Tell me with a straight face that it's not crazy to use a module and then be forced to list all of the methods that you want to import because it didn't define @EXPORT. Particularly when the only reason why someone would want to use that module is to get access t
        • Re: (Score:1)

          by chromatic (983)

          Tell me with a straight face that it's not crazy to use a module and then be forced to list all of the methods that you want to import because it didn't define @EXPORT. Particularly when the only reason why someone would want to use that module is to get access to those functions.

          The important difference is that roles have always had the explicit design goal of not enforcing any particular implementation decision to take advantage of them.
          • Re:On Warnings (Score:1)

            by btilly (5037) on 2009.04.25 15:48 (#68311) Journal

            The fact that someone has a legitimate design goal that creates action at a distance doesn't necessarily make the decision to create action at a distance a good idea.

            In a similar spirit I would not be opposed to an optional warning if my subclass overrode a parent class's method and didn't, say, provide an attribute that says, "Yes, this is an intentional override, don't warn." You might find having to type :override annoying, but I would find it invaluable. (I also know that I have a snowball's chance in hell of getting it to happen...)

            Reply to This

            Parent

            • Re: (Score:1)

              by chromatic (983)

              I believe it's easier to argue that inheriting or composing in methods is more action at a distance than declaring them locally. Perhaps prototype OO systems are clearest by this metric.