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.
  • Do you also want using 'sub foo {...}' to override a superclass method to be a compile-time failure or warning?

    If not, why treat it differently than overriding a role method, other than one's comparative level of experience and familiarity with inheritance vs. with roles?

    • Do you also want using 'sub foo {...}' to override a superclass method to be a compile-time failure or warning?

      Many language designers are now realizing that they need to be explicit in their code behavior. For example, here's a Java method which should override a parent class method.

      @Override
      public int someObscureMethod() {
         return 1;
      }

      What if the parent class method takes an argument? You've not overridden the method and you may very well get an extremely hard to debug error. Now you can find out at compile time that this method isn't really overriding anything. Here's the method in C#

      public override int someObscureMethod() {
         return 1;
      }

      Again, you'll find out at compile time if you didn't really override anything. You can also find out at compile time if a method overrides something but you didn't list it as overriding anything. This is very useful for the programmer. Now consider a common pitfall in C++:

      #include <iostream>
      using namespace std;

      class Base {
          public:
          void doit() {
              cout <<"base class"<<endl;
          }
      };

      class Derived : public Base {
          public:
          void doit()
          {
              cout<<"derived class"<<endl;
          }
      };

      int main() {
          Base *a, *b;
          a = new Base();
          a->doit();
          b = new Derived();
          b->doit();
      }

      That will print out "base class" twice, but that's not what you wanted. You need to declare Base::doit as virtual to get a dynamic binding instead of a static one. For a C++ programmer, when working in a derived class, the lack of annotation on the method can be very confusing and is apparently a common source of bugs, but at least by having the "virtual" keyword on the parent class you can see that it can be overridden (but it really belongs in the derived class).

      You can also take a look at Eiffel for even more extreme instances where they strive to make things clear for the programmer.

      In short, just because Perl makes it easy to screw up (did reciept() really override anything?) doesn't mean that it's a good thing. Many other languages are realizing this :)

      • I think hdp was asking an honest, simple question. I think your answer is "yes, subclassed override should also warn if not marked," with added explanation. Is that correct?

        I have no strong feelings either way, although I'd rather all my existing code didn't go crazy with warnings. I just wonder what your opinion is on other forms of method occlusion or augmentation.

        --
        rjbs
        • Yes, that was my intended answer. Many languages are moving to this, though I can see others resisting this idea.

          As for "other forms of method occlusion or augmentation", I expect you're referring to things like the "before", "after", "around", "augment" and "inner" features from Moose. "augment" and "inner" must go hand-in-hand, so that's immediately visible to the programmer no matter which of the augment/inner methods they see.

          The others are silent "action at a distance" but they have the advantage tha