Re: Non-philosophical definition of Eiffel?

[Hyman Rosen <hyrosen@mail.com>]

Dmitry A. Kazakov wrote:
> 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.

We need to look at this without using common English words
that will cause confusion:

     type Base is ...;
     function Affect(X : Base) return Base;
     type Derived is new Base ...;
     function Affect(X : Derived) return Derived;

Now if I have a Derived object attached to a Base'Class
reference, and I make a dispatching call, the Derived
Affect will be called, will return a Derived object, and
since a Derived object is a Base object, substitutability
is satisfied. If the Derived type, or the Base type, is
supposed to maintain certain invariants but the methods
fail to do that, then the methods are in error, but that
has nothing to do with LSP.

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

This is the correct answer.

> 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.

Nonsense. The only unsoundness here is the confusion between
abstract notions and and how they map into computer code. Your
use of the words "Ellipse" and "Circle" and "Resize" demonstrates
this. What is the computer-ellipse? If it is an object which has
independently resizable axes, and a computer-circle does not, then
a computer-circle is not a computer-ellipse, and can't be used in
places where computer-ellipses are expected. On the other hand, if
a computer-ellipse is an immutable object with a pair of axis sizes,
then a computer-circle can be written to fit that interface as well,
and can be used where a computer-ellipse is expected.

This is all perfectly obvious and has been talked about over and
over again. It's simply a matter of asking what operations a base
type supports, and whether a derived type can support all of the
same operations. Any notion that derivation within computer code
must somehow model abstract notions of the real world is wrong,
and leads into confusion and error.

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

Does it? Do you have an example? I'm not sure that it's the
same thing, but we'll see.

>>f5) Covariant argument types.
> 
> Yes, but again, you cannot solve this.

You "solve" it by not doing it.

 > 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.

I forget. Does Ada let you pass a Positive object to a
procedure expecting an Integer out parameter, and range
check the assignment, or does it forbid such a call? If
it's the former, then LSP is in fact preserved, in that
the same set of operations are permitted. The operation
may throw an exception, but it's present. That's the same
thing as implementing Circle.Resize and having it throw
if the two axes are not specified to bethe same size.