[shiro]

Right, if you take type-safety first, you shouldn't be able to. But a list of abstract fruits has very limited usage without the ability to accessing concrete fruit instance. The adoption of downcasting in some OO languages came out from such needs, given that they lacked generic and/or algebraic types. And with that regard, I thought your solution didn't address the original covariance/contravariance problem (that is, want to have heterogeneous list of fruits and allowing to access concrete types of individual elements).

There are type-safe ways, like making a fruit a sum type of apple and banana, or using traits or type classes, etc. But is-a/has-a discussion seems a bit off from that.

[catnaroek]

> I thought your solution didn't address

FWIW, I didn't propose the original Scala snippet, so it isn't really “my” solution.

> the original covariance/contravariance problem

The problem is precisely preventing what you're trying to do, because it's unsafe.

[shiro]

Ah, ok, I mixed up you with continuational.

For this context, what I'm saying is that if you don't need to extract an apple from a list of fruits, then you can do it safely with inheritance, so whether using inheritance or delegation is irrelevant. Isn't it?

[catnaroek]

If you want to extract an apple from a list of fruits, you need runtime type information (so that you can test whether a particular fruit object happens to be an apple), which has nothing to do with whether your language has inheritance or not. Using runtime type information is a symptom of bad design, though, since it lessens the extent to which you can reason about programs (as pieces of text) by just looking at their types.

[shiro]

I agree with you all. All I say is that suggesting delegation in place of inheritance to address contravariance issue seems off the mark.