Re: Ada Interfaces and the Liskov Substitution Principle

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

On Thu, 24 May 2007 13:12:56 +0200, Stefan Lucks wrote:

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

If it dealt with T, then the following program were legal:

   procedure Foo (X : in out T);

   procedure Bar (X : in T) is
   begin
      Foo (X):  -- Fortunately illegal in Ada
   end Bar;

> The "in" is part of the 
> subprogram's contract, not a part of X's contract. So there is no conflict 
> with LSP.

But:

1. either the subprogram is a primitive operation then its contract is a
part of the type contract => subject of LSP.

2. or it is not, and then substitutability does not apply (the type does
not change) => absolutely substitutable anyway.

> Perhaps you should follow the crowd and 
> narrow your interpretation as well?

Yes, but then LSP should be re-formulated appropriately. And there is
nothing automatically wrong in disallowing operations. I would like to see
it in Ada.

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

Yes, this is a problem. In particular, when some property (like
Constraint_Error propagation because of substitutability violation) becomes
determinable in some, but all context. The language designer has no choice
to make it illegal. The best thing he can do is to spill a warning. This is
a way too little.

There should be a way to have a finer grained classification of
substitutability contexts than everywhere vs nowhere, such that the
programmer could help the compiler by specifying the contexts where
indeterminable substitutability were an error.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de