Re: Ada Interfaces and the Liskov Substitution Principle

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

On Fri, 01 Jun 2007 06:32:30 -0700, Maciej Sobczak wrote:

> On 1 Cze, 09:29, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
> 
>> You are trying to invent some alternative meaning for class-wide.
> 
> Not really.
> There is a difference between this:
> 
> X : T'Class := Y;
> 
> and this:
> 
> X := Y;  -- with X, Y : T'Class;
> 
> The difference is coming from the fact that T'Class gets bound at
> initialization only and cannot change its binding (tag for you) later
> on (X cannot change the actual type).

This is a constraint. It does not change the meaning of T'Class.

The pragmatic argument is that this constraint cannot be checked at compile
time, so you cannot make it illegal.

The formal argument is that values of T'Class are supposed to mimic ones of
the specific types from class T (generic programming etc). So IF T (the
root type of the class) has a primitive subprogram F then T'Class shall act
on it. This is the definition of class and primitive subprograms of. In
particular, if T has ":=" that is equivalent to polymorphic ":=" being
defined on T'Class. There is no obvious way to change this, otherwise than
by providing another definition of T'Class and class T and primitive
subprograms of or claiming that there is a semantic difference between X:=Y
and Assign(X,Y). I don't want a language with magical, semantically
non-decomposable assignments.

[Contravariant operations of T'Class have been discussed earlier]

> In other words, X can become equivalent to Y by initialization, but
> not by assignment. The latter is already too late - you might be
> assigning Triangles to Circles.
> This is what makes T'Class different from T.

No, it makes different construction from example and assignment. They are
indeed different, however one could be defined in terms of another. But
this by no means influences the semantics of T'Class.

>>> You don't need to assign it. It is enough if you can replace it.
>>
>> Care to explain difference?
> 
> You can replace a Circle with a Triangle but you better not try to
> assign them.

This is not an explanation. Show a semantic difference between changing a
name binding from one value to another by A) "replacement" and B)
"assignment."

Ah, wouldn't replacement double dispatching? Then let "assignment" :=
"replacement," and we are back where we started from. (:-))

> No, hierarchies and values don't go together. I might lack the
> formalism to prove it, but my observations are confirming: I've never
> seen it in the wild.

Lacking formalism is not an excuse, it is an indictment. (:-))

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