Re: Non-philosophical definition of Eiffel?

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

On Wed, 30 Jul 2003 12:38:35 -0400, Hyman Rosen <hyrosen@mail.com>
wrote:

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

No it isn't. You forgot semantics. LSP is all about semantics. The
problem is that Affect returning Derived just cannot be implemented in
Cricle/Ellipse case. This problem appears each time a derived type is
a specialization of the base. Specialization breaks out-methods.
Covariant result is a case of out-method. Period.

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

What does it mean to "be in error"? The contract of Base does not
mention "being in error". So it violates the contract and thus LSP.

>> ---- LSP-abstinence-syndrome
>> Hey, "computer circles" are not "computer ellipses"!
>
>This is the correct answer.

Yes, but it does not imply that Circle shall not be a subtype of
Ellipse. In a real system it will, because code reuse is more
important than far-fetched absolute LSP. It is clear that an absolute
substitutability cannot be enfoced by any means. The real solution is
a context-dependent substitutability and type systems helping in
checking it as much as possible.

>> 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 one of many ways of defending [absolute] LSP. Surely if you
are dealing with something so airy which cannot be expressed
mathematically, then you simply cannot disprove it mathematically.
(:-))

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

This exactly means to be mathematically unsound.

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

Class-wide arguments are not controlled, they are not inherited when
you derive. Because a class-wide argument is a closure of the set of
all derived types.

type Base is tagged ...;
procedure Foo (X : Base'Class);
type Derived is new Base ...;
   -- Foo is same for Derived and it is not inherited

One could say that class-wide arguments are contravariant, but this
would be imprecise, because no type conversion to the base type
happens. However, the effect is same [as long as redispatch supported
through an embedded type tag] 

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

Yes.

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

It is so:

1. if Constraint_Error is a part of the contract of the procedure then
LSP is preserved with this regard. As I said to add all imaginable
exceptions to all contracts is a possible way. Unfortunately it is
great burden and it erodes the idea of checkability.

2. if Constraint_Error is not in the contract. then LSP is violated.

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

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