Re: Non-philosophical definition of Eiffel?

[Hyman Rosen <hyrosen@mail.com>]

Dmitry A. Kazakov wrote:
> How could it be otherwise?
> [If the argument type is contravariant, then the subroutine is not a
> method in this argument => it is not inherited.]

It could be, in some other language. You could explicitly designate
which method was being overridden, and allow contravariant arguments.

> That's not Effel's problem. This a problem of type specialization
> which inevitably breaks out-methods. Nothing can be done about it.

You can disallow it! Eiffel's problem is that it allowed such things
without a good way of avoiding errors at the call sites, short of
whole-program verification or runtime type checks.

> BTW, generalization breaks in-methods. In short, the notion of
> absolute substitutability (the way many are treating LSP) is useless
> absolutely.

OO programming in its most mechanical sense involves derived classes
overriding base methods, and allowing those methods to be invoked by
things which know only the base. You can break that paradigm if you
want, but then you should probably call it something else, so you don't
confuse people.