All the Perl that's Practical to Extract and Report

Navigation

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Without JavaScript enabled, you might want to
use the classic discussion system instead. If you login, you can remember this preference.

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.

@Overridepublic 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++:

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

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