Re^4: Understanding 'Multiple Inheritance'

Polymorphism encourages encapsulation, but absolutely requires inheritance.
Completely false.

? Not just "false" but "completely false"? So polymorphism neither encourages encapsulation nor requires inheritance?

This is not polymorphism, this is overloaded functions, as in multimethods of perl 6. Your methods are, more or less:

sub quack(RubberDuck $self) { ... }
sub quack(Mallard $self)    { ... }
[download]

This is not polymorphism. Overloadable functions (same name, different contents) are usually found only in OO languages, but I don't think that this is causal. I think C may have overloadable functions in the not-too-distant future, if it doesn't already in the latest spec.

package RubberDuck;

sub new { bless {}, shift }

sub make_noise { print "Plug yer ears!\n"; $_[0]->quack(); }
sub quack { print "Squeak!\n" }

sub DESTROY { print "RubberDuck goes back in the toybox.\n" }

package Mallard;

our @ISA = qw(RubberDuck);
sub new { bless {}, shift }

sub quack { print "Quack!\n" }

sub DESTROY { print "Mallard flies away.\n" }

package main;

for my $duck_class (qw( RubberDuck Mallard ))
{
    my $duck = $duck_class->new();
    $duck->make_noise();
}
[download]

This is polymorphism. The parent class calls a function in the parent class, but the derived class gets to intercept it and do stuff with it. That stuff may include calling the parent class, or, as in this example, it may not.

Comment on Re^4: Understanding 'Multiple Inheritance' Select or Download Code

Replies are listed 'Best First'.
Re^5: Understanding 'Multiple Inheritance' by chromatic (Archbishop) on Mar 07, 2005 at 22:06 UTC
So polymorphism neither encourages encapsulation nor requires inheritance? Yes, that's exactly right. You can have polymorphism without inheritance. You can have object orientation without inheritance. (Consider a prototype-based languages such as Self or JavaScript.) Almost no book or tutorial on object orientation explains that well, but that's a failure of imagination at best. This is not polymorphism, this is overloaded functions... My code declares two classes with identical interfaces and similar semantics. The classes have no relationship code-wise, neither sharing code nor inheriting from each other or from a common ancestor. Yet the main package treats objects of both classes identically, semantically and code-wise, and it works. How is that not polymorphism? Where is the overloading? This is polymorphism. Yes, your code also shows polymorphism -- specifically sub-type polymorphism. That's not the only type of polymorphism, however, and it's certainly not always the best type.	[reply]
Re^5: Understanding 'Multiple Inheritance' by tilly (Archbishop) on Mar 08, 2005 at 02:08 UTC
You and chromatic are defining polymorphism differently, and then disagreeing about whether his example is polymorphism. But the thing is that his implicit definition is both more useful and more standard. Polymorphism is the ability for different data types to go through the same code and automatically be treated appropriately. One way to generate different data types that you might do this is to have a class and a subclass. (Or to have 2 subclasses.) But there is, in general, no need for them to be related in any way. It is just often convenient for them to be connected.	[reply]