Talk:Covariance through renaming

The key insight here is that it is inappropriate and unworkable to try to use the type system to model the eating habits of herbivores. Any real-world animals will have eating preferences too complex to model through the type system anyway, even if it did not cause catcalls.

The precondition "likes" solves the problem. And once you have the problem solved this way, there is no need for the renaming and the introduction of new, unrelated 'eat' features in descendants. Just redefine "likes" for each kind of animal. Eiffel 12:38, 22 February 2007 (CET)

Which does not solve the problem of covariant arguments, for example when you want to add a postcondition to 'eat' the needs to talk about the fact that grass was eaten. --Schoelle 15:08, 22 February 2007 (CET)

--manus 17:43, 22 February 2007 (CET) One of the issue of the proposal is that it is more or less what the other languages are currently using to fake covariance. So Eiffel would not be in a better position, this is why I think we should find a solution not involving the addition of new routines.

I really cannot understand what 'fake covariance' is. We are facing a modelling problem and that needs to be adequately solved. My suggestion tries to show that there is a certain class of problems that are normally called good examples for the need of covariance (CAT_SKIPPER, ANIMAL/COW) that can be solved purely by renaming, without any loss of precision or generality. The problem of 'implicit covariance' through generic parameters seems to be the only reason to support covariance (although this is indeed a hard problem). --Schoelle 19:54, 22 February 2007 (CET)

--Peter gummer 01:36, 25 June 2007 (CEST) The problem with this solution is that it is complex, so the initial programmer is likely to make a mistake and the maintenance programmer is going to find it difficult to see the relationship between the parts, especially in a large class. It's harder for the novice to learn this pattern than to use covariance. It's not true to say that this class of problems "can be solved purely by renaming". The two examples show that it's done by renaming plus an assignment attempt. I've used a similar technique in Delphi (the redefine method modifier plus a typecast); I've also used the same technique in C# (except that the method modifier keyword is new). This is exactly the sort of horrible solution that I want to avoid; it's complex and error-prone. Eiffel's catcall problem rarely occurs in practice: far more rarely than typecasting errors in other languages. I remember being bitten by catcalls twice in my early Eiffel-programming days; since then I don't recall it ever having happened to me again. I suspect that it's something that tends to happen to novice Eiffel programmers, but once you know what you're doing you almost never make that mistake. Assignment attempt is essentially a typecast, so "covariance through renaming" trades a largely theoretical problem for a major practical problem.