So what's the problem with doing interfaces with Perl?
Perhaps a better question is "what's the problem with doing interfaces in Java?" The answer is "plenty." By understanding why Java has interfaces in the first place (something you alluded to but didn't go into) we can better understand the interface and it's potential relationship to Perl.
When Java was created, its designers realized that multiple-inheritence (MI) is a source of many bugs. As with many other things in Java, the designers decided that things that are bug prone will be handled with a straightjacket and strict discipline. This bondage-and-discipline approach to the language led the designers to conclude that MI is so problematic that, rather than trust programmers to be able to wisely use their judgment, they'll just take it away. Instead we get the cruft that is the interface.
The big win with MI, of course, is software reuse. Now, instead of reimplementing that foo() method, we can simply inherit from Yet Another Class and get the foo() method for free. Of course, if that other class really is not an appropriate base class, we might wind up with compositionally unsound classes. Delegation can sometimes solve this, but not always. We also wind up with ordering problems in MI and other subtle design issues that are beyond the scope of this discussion.
So Java says "we do not trust you with MI, you must use interfaces instead." And this is when Java programmers discover the mixed blessing of interfaces: they're a great tool for maintaining consistent interfaces across various classes, but the completely destroy the idea of software reuse. Every time you use an interface, you must reimplement what is essentially the same method. Using interfaces in Perl means that not only do we have to reimplement the same methods, we don't even get the benefit of declaring a signature or a return type, thus eliminating one of the few benefits that interfaces really provide.
Ruby has also tried to solve the MI problem by using mixins. They're nice, but they have the same ordering problems as MI and this can be frustrating. A better way of solving this problem is to use traits, an implementation of which can be found on the CPAN as Class::Trait. Perl6 will have "roles" which are essentially traits. Unlike Ruby and Java, however, MI will not be forbidden (to me it seems silly to throw away a problematic but useful tool in favor of one that's unproven.)
That's not to say that I'm totally down on interfaces, but I'm not a huge fan of them. Java showed us a brilliant way to not solve the MI problem and I can't say that I entirely trust them in Perl. I do use them, however. Quite often I don't give a fig about what class an object is, but I do care about whether or not it can respond to a particular set of methods. I sometimes have classes store an object in a slot and delegate several methods to that object. Frequently I don't care what class is in that slot but the object had better respond when I call the methods that I need. Perl's poor argument handling still limits the utility of this, but then, if we're insisting that everything be perfect, we wouldn't be using Perl, would we?
Cheers,
Ovid
New address of my CGI Course.
In reply to Re: interface.pm explained
by Ovid
in thread interface.pm explained
by gaal
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |