Re: Ada Interfaces and the Liskov Substitution Principle

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

On 3 Cze, 09:09, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> > Yes, replacement can change the tag. It's the tag of referred object
> > that can change. An access variable can point to Circle and then to
> > Triangle.
>
> No, this is illegal. At least in Ada,: access Circle and access Triangle
> are different types. They cannot be assigned to each other.

I was talking about access Object'Class with Circle and Triangle being
both derived from Object.
The access variable can point to object with different tag during its
lifetime.

> >>>> Ah, wouldn't replacement double dispatching?
>
> >>> No, it wouldn't and that's the second difference. Replacement just
> >>> gets rid of the current value before the new value is refered to,
> >>> which means that from the dispatching point of view this operation is
> >>> simply linear on right-hand-side - it's a pure single dispatch.
>
> >> No, this does not work. Apart from being semantically wrong in general
> >> case, it is technically wrong.
>
> > Why is it semantically wrong?
>
> Because variables of T'Class can be assigned with the values of T'Class if
> T has assignment.

We are going in circles. I say T'Class should be limited.
Even if T is not.

> >> You have to dispatch to finalize LHS. You
> >> have to dispatch to re-construct it from RHS.
>
> > It doesn't change anything in my reasoning. Two linear dispatches
> > don't magically give you double dispatch!
>
> Of course it does. A function of two arguments is still a function of two
> arguments. Decomposability of the function into a product is irrelevant to
> the issue. It dispatches in both arguments.

It doesn't change anything.
Think about extensibility of the system. One of the virtues of OO is
the ability of the system to be reused with new types. If you have a
hierarchy with N types then adding new type means you have to
implement 1 finalizer and 1 cloning (if you want them, of course) and
all replacement semantics in the system still works fine. In other
words, you don't have to involve all other types in the hierarchy when
implementing a new type.
With doubly-dispatching assignment, adding new type to the same
hierarchy means you have to implement N assignments for each potential
situation.
Or even 2*N.

Now think about the hierarchy that has many branches which are
extended independently...

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.

> Not at all. The point is:
>
> limited T <=> limited T'Class
>
> No more, no less.

That's your point. Mine is T'Class should be limited.

> The issue of identity / references you are trying to bring in is
> irrelevant. Multiple dispatch assignment is fully applicable to wheel and
> car objects. When you "replace" wheels, you could perform different tasks
> depending on the types of the old and new wheels .How these tasks can be
> encapsulated into one replacement action?

They are not. That's the feature of replacement.

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?
Right?
Unfortunately, this is completely broken in Ada.
This is just another reason why doubly-dispatching assignment cannot
exist. Not only it's unrealistic to implement correctly (remember the
complexity), there is simply no reasonable structure to build upon.

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