Re: Non-philosophical definition of Eiffel?

[Dmitry A. Kazakov <mailbox@dmitry-kazakov.de>]

On Tue, 29 Jul 2003 12:35:57 -0400, Hyman Rosen <hyrosen@mail.com>
wrote:

>Dmitry A. Kazakov wrote:
>> There is little sense in contravariant arguments
>
>OK, I just want to make sure that we're talking about
>the same thing, so let me give specific examples. I'll
>write in C++ terms, just because.
>
>     struct B1 { };
>     struct D1 : B1 { };
>
>     struct B2
>     {
>         virtual B1 &f1();
>         virtual B1 &f2();
>         virtual void f3(B1 &);
>         virtual void f4(D1 &);
>         virtual void f5(B1 &);
>     };
>
>     struct D2 : B2
>     {
>         B1 &f1();
>         D1 &f2();
>         void f3(B1 &);
>         void f4(B1 &);
>         void f5(D1 &);
>     };
>
>     D2 d2;
>     B2 *b2 = &d2;
>
>f1) This is ordinary overriding, with same return type.
>     Pretty much legal in every language.
>f2) This is covariant return type. Legal in C++. This
>     preserves LSP, since a call b2->f2() must return a
>     B1 &, and a D1 & is a B1 &.

Covariant return type does not preserve LSP. There is no thing which
does. Everything depends on the concrete situation. Here is a famous
example where covariant result breaks LSP:

type Ellipse is ...;
function Resize (X : Ellipse;...) return Ellipse;
type Circle is new Ellipse ...;
function Resize (X : Circle;...) return Circle;
   -- Breaks LSP, not every circle, being resized yields a circle.

Typical solutions are:

----- Contravariant result
type Ellipse is ...;
function Resize (X : Ellipse;...) return Ellipse'Class;
type Circle is new Ellipse ...;
function Resize (X : Circle;...) return Ellipse'Class;

----- Exceptions
Resize_Error : exception;
type Ellipse is ...;
function Resize (X : Ellipse;...) return Ellipse;
   -- May raise Resize_Error, but will not
type Circle is new Ellipse ...;
function Resize (X : Circle;...) return Circle;
   -- May raise Resize_Error, and will

---- LSP-abstinence-syndrome
Hey, "computer circles" are not "computer ellipses"!

The mentioned and all other "solutions" have various disadvantages.
The real problem is that it is fundametally unsolvable. One could
easily see that LSP is mathematically unsound, should one try to
define it formally.

>f3) Again, ordinary overriding, with the same argument
>     types in base and derived. Legal everywhere.
>f4) Contravariant argument types. This also preserves
>     LSP, but I don't know of a language which implements
>     it. LSP is preserved because a call of b2->f4() can
>     only pass a D1 & argument, and a D1 & is a B1 &.

Ada does this. It is a class-wide argument.

>f5) Covariant argument types. This is Eiffel's model.
>     LSP is not preserved, because a call to b2->f5()
>     may pass any B1 &, while d2.f5() wants only a D1 &.

Yes, but again, you cannot solve this. It is mother nature which
decided that no positive number have an inverse. So subtype Postive is
Integer ...; inevitable breaks LSP. You just have to decide what do
you want, [an absolute] LSP or positive numbers. I vote for positive
numbers.

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de