Re: Ada Interfaces and the Liskov Substitution Principle

[Stefan Lucks <lucks@th.informatik.uni-mannheim.de>]

Dmitry A. Kazakov wrote:

> [...] mere passing a variable as "in" does it as
> well in the sense that "in T" is not an LSP-subtype of T.

You are using a very broad and generalised interpretation of the LSP. My 
interpretation -- and I believe this is the common and usual one -- is 
that "X: in T" in the parameterlist of a subprogram does not deal with 
some "artificial" type "in T", just with "T". The "in" is part of the 
subprogram's contract, not a part of X's contract. So there is no conflict 
with LSP.

> LPS is totally irrelevant as long as substitutability violation can be
> detected at compile time. This is why "constant" does not worry anybody. A
> method disallowing is perfectly OK, if you cannot call it.

So your very broad and generalised interpretation of the LSP is totally 
irrelevant, except for the special case where it overlaps with the more 
narrow usual interpretation. Perhaps you should follow the crowd and 
narrow your interpretation as well?

Whatever interpretation, the stuff below is right.

> LSP violation becomes a problem when substitutability is indeterminable
> until run-time. In may cases we still choose to live with that. Constrained
> Ada subtypes is an example of. Another is multi-methods Foo (X, Y : T),
> when called on different children of T. In such cases Ada adds
> Constraint_Error to the interface of each subprogram and things become
> "substitutable" again.

Yes, that is an ugly patch. But it appears tricky to come up with a better 
solution ...

> LSP violation is catastrophic when undetected. [...]

It is bad enough if detected after lengthy testing and debugging sessions.



-- 
Stefan Lucks      (moved to Bauhaus-University Weimar, Germany)
------  I  love  the  taste  of  Cryptanalysis  in  the  morning!  ------