Re: Ada Interfaces and the Liskov Substitution Principle

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

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.
Thanks to this, access T'Class can be used to provide replacement
semantics for T'Class, where assignment wouldn't work.

I believe I get the Ada basics right.

> > 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*.
Of course, there is a place for constant access Whatever, but this is
another story.

> > You can theoretize as long as you want and you can say (even rightly)
> > that replacement is doubly-dispatching, but there *is* a difference
> > between O(n+m) and O(n*m) - and this difference is what makes
> > assignment of T'Class simply unrealistic.
>
> No, that makes it unrealistic to manage this complexity using crude
> patterns instead of a consistent approach. The problem is here, the choice
> is between language support and manual cascaded case-statements.

No, there is no choice whatsoever. There is nothing that cascaded case-
statements can buy you that you couldn't do with dispatch (except
maybe static coverage tests - but these don't exist in open
hierarchies).
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);
  -- oops
end;

It does not matter what is inside Swap. Double-dispatch, cascading
case, unchecked magic, whatever. These are all low-level details of
something that just doesn't fly anyway.

> > This, however, brings another point - if you want to execute different
> > assignment tasks depending on both LHS and RHS *types*, then let's
> > extend it a bit: I want to execute different tasks depending on
> > current *values* of both LHS and RHS. After all, if assignment is
> > supposed to be doubly-dispatching and if it's also supposed to be no
> > different than hypothetical Assign(X, Y), then I should be able to do
> > this, right?
>
> 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.

> In some cases you might really want LHS being finalized
> before the overridden part of the assignment, like when it holds an
> expensive resource.

1. In *some* cases. In those cases I can take this decision on my own.

2. Actually, in those cases when LHS keeps expensive resource I would
very much welcome the ability to reuse it, if possible. Consider:

declare
   S1 : My_String_Type := "abcd";
   S2 : My_String_Type := "xyz";
begin
   S1 := S2;
end;

No need to finalize LHS here (and reallocate again to hold a copy of
RHS). Other examples abound.

Sorry to say this, but when I see things like *this*, I have an
impression that Ada is SbyC (Slow by Construction - you can quote
me :-) ). This is *obvious* optimization opportunity!

But that was aside, nothing about T'Class being limited.

> My approach, not shared here, is that the programmer should have more
> control over this, when he wants.

Hm... do we agree again? :-)

> The constructors, destructors,
> assignments and aggregates are all polymorphic subroutines composed
> differently from normal primitive and class-wide operations.

Agreed with exceptions:
- constructors cannot be polymorphic, since there is no tag yet (you
might dispatch on something different, though, but this is irrelevant)
- assignments are banned anyway ;-)

Destructors are obviously polymorphic.

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

> > Unfortunately, this is completely broken in Ada.
>
> It is not broken, it does not exist. Adjust is not an assignment, it is
> hack to provide functionality without much rethinking.

Hacks make things broken.
Every language has its hacks, but this one is just too fundamental to
be easily forgiven. ;-)

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