Re: Ada Interfaces and the Liskov Substitution Principle

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

On Mon, 04 Jun 2007 10:02:48 -0700, Maciej Sobczak wrote:

> On 4 Cze, 10:08, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
> 
>>> I was talking about access Object'Class with Circle and Triangle being
>>> both derived from Object.
>>
>> What is the difference between the types access T'Class and T'Class?
> 
> Access T'Class can be reseated to point to some other object from
> T'Class, even if that other object has different tag.

So what? According to you that is wrong because there exist n*n possible
combinations of such assignments for different tags. In what sense these
combinations are different for T'Class and access T'Class?

>>> We are going in circles. I say T'Class should be limited.
>>> Even if T is not.
>>
>> If I'd say access T'Class should be limited even if T is not?
> 
> No, access Whatever should not be unconditionally limited, otherwise
> there would be little justification for its existence in the type
> system.
> The raison d'etre for access T is the ability to *point* - and be
> *reseated*.

While for T'Class it is the ability to accommodate any specific T. Where is
a difference?

> There are fundamental reasons for which assignment for T'Class doesn't
> make sense (it would lead to objects that can change type at runtime -
> you cannot get further away from Ada than that) and no matter what
> magic you try, you will always hit the same wall.
> Consider (again):
> 
> procedure Swap(X : in out Object'Class; X in out Object'Class)
> begin
>    -- whatever
> end Swap;
> 
> and then:
> 
> declare
>   X : Triangle;
>   Y : Circle;
> begin
>   Swap(X, Y);

procedure Swap (X, Y : in out String);

declare
   X : String := "abc";
   Y : String := "klmnoprst";
begin
   Swap (X, Y);
   -- oops

Why your "fundamental" reasons do not apply here?

The only truly fundamental reason is that if Object was declared
non-limited, then its contract is to support assignment. It is then the
programmer responsibility to fulfill this contract for Triangle and Circle.
Don't blame the language for your own design faults.

>> Wrong. These are independent. Double dispatch controls the choice of the
>> specific body, it tells nothing about how this body has to be assembled.
> 
> Yes, but this shows that assignment in Ada cannot be modeled by any
> hypothetical Assign subprogram. No analogies here. This in turn means
> that introducing full double-dispatch to the discussion doesn't help
> much, because implementing it would not be at all similar to anything.

It is still independent. The thing is not fully decomposable into
subprograms because that would require type violation, which is impossible
in a typed language. Therefore some magic is needed to convert raw memory
to an object and back. This is irrelevant to dispatch. And if that were a
reason to forbid assignments, then *any* assignment would become illegal.

Because magic is needed, assignment, construction and destruction will
always be compiler-generated with some injections of user-defined
subprograms at the points where necessary [sub]objects are fully
constructed/destructed. This is no different from polymorphic subprograms,
they are also compiler-generated.

>> My approach, not shared here, is that the programmer should have more
>> control over this, when he wants.
> 
> Hm... do we agree again? :-)

No, because you want to disallow assignment altogether, others want to keep
it albeit sometimes inconsistent, but I want to change the language to have
a way to enforce its consistency.

> - constructors cannot be polymorphic, since there is no tag yet (you
> might dispatch on something different, though, but this is irrelevant)

There is the tag, it exists before the object and comes from the type of. A
constructor (actually a part of) dispatches on the bare tag. I posted a
description of my view on this some time ago:

http://groups.google.com/group/comp.lang.ada/browse_thread/thread/72c34c66b38e0e05/b4b6668d530912ac?lnk=gst&q=kazakov+construction&rnum=6#b4b6668d530912ac
 
>> In a better
>> language one should be able to describe all these decompositions uniformly,
>> with a higher-level mechanism of polymorphic subprograms.
> 
> Not really. The problem is that these things work on the border of
> object's life and death and for this reason they cannot be first-class
> citizens in the world of polymorphic operations.

The same applies to primitive operations. Dispatch happens per magic. I
suppose there is a more general mechanism based on types constraints. But
in any case it will be "magical." But that will be the only magic
necessary.

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