Re: Ada Interfaces and the Liskov Substitution Principle

[Maciej Sobczak <see.my.homepage@gmail.com>]

On 5 Cze, 10:35, "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?

In the sense that access T'Class has only one combination to cover and
since access is a fundamental type, this is handled by the language.
You don't have to do anything to make assignment for access T'Class
work!

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

In assignment.

(We are really going in circles.)

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

OK, even better. Let's ban assignment for all unconstrained types. :-)

> Why your "fundamental" reasons do not apply here?

The "fundamental" reasons apply here as well. The problem is of a
general nature.

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

No. Regular objects are declared as Triangles and Circles (and these
types may have reasonable assignments - after all, assigning one
Triangle to another makes sense). The problem is when you declare
something as T'Class.
T'Class /= T and this is one of the things that make them different.
I know that it shakes part of the concept of a class.

But you have the same problem with unconstrained types. They might not
support all operations of their constrained equivalents.

> > - 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 don't agree on this.

X : T;
Y : T'Class := Whatever;

Do_Something(X); -- (1)
Do_Something(Y); -- (2)

Which of the two above are dispatching (assume Do_Something is
primitive)?
My understanding of the concepts is that only (2) is a dispatching
call, (1) is not.
The constructors are non-dispatching, no matter how much of the "fetus
object" is there when the call is made. Even if there is a tag, it's
known statically and then this is just overloading, not polymorphism
in the OO sense.

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

Still, there is a difference between T and T'Class. As far as I
understand it, constructor calls are not dispatching.

--
Maciej Sobczak
http://www.msobczak.com/