contravariant argument types: wanna?

[Andrei Alexandrescu]

Jeremie Pelletier wrote:
> Have you read my other post in this thread where I show an actual 
> example of covariant arguments from my display interface, my I/O 
> interfaces also use covariant arguments although they're more friendly 
> to generic interface parameters.

I did. I don't have enough information to comment on the design, but at 
the end of the day, statically-typed OO designs should be for families 
that have many commonalities and few differences. As such, access to the 
interface should be everything needed for carrying out most tasks. 
Maintaining two parallel hierarchies in which each of them must cast 
around from the least capable to the concrete one is, I think, a design 
due for some improvement.

A derived class does not "extend" its base class. It specializes it, 
because the base class represents an archetype for a variety of types, 
including the derived class but much larger. So a Mammal doesn't quite 
"extend" Animal because Animal includes all animals, mammals and 
reptiles and whatever. If anything, Mammal narrows the inheritance cone 
from under Animal. Indeed Mammal does add state, but Animal should not 
be considered holding its state; it's holding its own state plus the 
unrealized state of any class inheriting from it.

Unfortunately many designers today are blocked in the "inheritance 
extends" view of things. They define a base class or interface first 
with a narrow set of primitives, and then they "extend" it by defining 
new methods, which works exactly against object orientation. Every new 
method that's not in the parent class is an invitation for casting and 
against reuse and genericity. Ironically, Java put that characterization 
straight in the language, furthering the legitimacy of bad designs. A 
good OO design defines abstract yet _capable_ generic interfaces that 
suffice for achieving complex goals, and then implement them in concrete 
classes. Very rarely if ever should a piece of code know the exact 
implementation of an interface.

I am considering discussing all of the above in detail in TDPL, but I am 
afraid that some refugees from other languages will be shocked.

> The point is, you see covariance all the time in interface programming 
> when implementations expect an interface argument to be an object from 
> that same implementation. As soon as you use an abstract factory to let 
> the world use some implementation without being aware of which one it 
> is, you're bound to see covariance at some point. Most people just code 
> it explicitly, the mozilla code is *full* of explicit covariant 
> interface requests.
> 
> While they may not be sound, its still a scenario you're gonna come 
> across sooner or later, and a scenario which involves lots of similar 
> boilerplate that can easily be generated by the compiler.

The "capability cast" scenario could occur now and then, but if it's too 
frequent it reflect a problem in the design, not in the language 
implementing it.


Andrei