Contravariance [Was Re: what is easier to learn first?...]
gmcm at hypernet.com
Wed Mar 22 14:30:46 CET 2000
D. Michael McFarland writes:
> >>>>> "WT" == William Tanksley
[ Eiffel ]
> WT>... I don't agree with the author re: contravariance
> WT> versus covariance.
> Twang! (Sound of an engineer being clothes-lined by a CS concept)
That's OK. Engineers are cheap <wink>.
> "contravariance" and "covariance" here caught my eye.
> I hate to reveal my ignorance to this group (again), but I have to
> ask: What do these terms mean in this context?
You've gotten a couple replies that made me doubt my own
understanding. The two together are sometimes known as
"substitutability", which says, that when creating derived
classes "require no more, promise (or deliver) no less". One of
those is the "co" and the other is the "contra".
"As the types of output parameters and return values can thus
be varied in the same direction as the types of the containing
interfaces, this is called covariance."
"As the types of input parameters can thus be varied in the
opposite direction of the types of the containing interfaces,
this is called contravariance."
As "require no more, deliver no less" it makes sense, and
despite the rantings of that well known lunatic <wink>, Mr.
Tanksley, is a worthy goal.
The trouble starts when you make this dogma. There are lots
of times when the easy / sensible / intuitive way of doing
things violates this rule, (eg, the example another poster gave
of Animal eats food, but Carnivore eats only meat - another
case is frameworks which almost always violate these rules).
Then you either end up turning the world inside out so it will fit
the rules, or you start legislating exceptions (which is what
So, in the first case (turning the world inside out), we would
declare that Food is an output of the Eats method, and
actually feeding the poor things is outside the scope of the
The debate waxes long and loud on comp.lang.object, but
don't go there. Read Dante's Inferno instead.
More information about the Python-list