Re: Ada Interfaces and the Liskov Substitution Principle

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

On 2 Cze, 10:19, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> > The difference is that (in Ada terms) replacement
> > allows you to change the tag. Assignment cannot do this.
>
> Neither can.

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. This is the kind of replacement I'm talking about.
But you cannot assign Triangle to Circle.

> But to show this we'd need to formalize it. Briefly: types
> access T and T are different types.

Sure. It's just not the type of reference I'm interested in in a
regular program, but the type of referred object.

> The semantic of assignment of access T
> is not one of T, and neither is of the assignment of T'Class! It is a typed
> language, after all...

Of course. That's why it is useful to distinguish them. And since we
came here from the notion of strategies (in strings, but that was so
long ago that it barely matters now), then replacing one strategy with
another can be implemented in terms of assigning access variables. It
is just not the level of abstraction I'm interested in. I don't care
about access variables. What I care about is the fact that I can
replace one strategy with another.

I can also replace a wheel in my car but it's not assignment of
wheels.

Replacement and assignment are different things from the design point
of view, even if replacement for T is implemented in terms of
assignment for access T - that's just not the level of detail I care
about.

> >> 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?
Consider replacing wheels in your car.

> 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! In terms of implementation
complexity, it is O(n+m) problem, not O(n*m).

The difference comes from the fact that finalizing LHS has no
influence on re-constructing from RHS.

> > Assignment has to be '2D' with both axes, or O(n2) in terms of
> > implementation complexity. It has to be double-dispatching to make any
> > sense and this is unrealistic implementation-wise.
>
> It is semantically this way. There is nothing to do about it, but to scrap
> either assignment or class. (We are going in circles)

That's exactly what I'm talking about from the very beginning -
T'Class should be limited.
Is it only my impression that we actually agree? :-)

> (C++ OO model is really poisoning. Don't mix types, just don't.)

In what way is the C++ OO model relevant here?

I'm talking about replacing wheels in my car. Twice a year I *replace*
summer wheels for winter ones and the other way round. I *don't
assign* them.


> Take what you wish, but referential semantic is fundamentally insufficient,
> in the sense that you cannot have a language without values, but only
> references.

Of course, I've never said that. You need both to do anything useful.

> Once you had at
> least one value at the end of the referential chains, you'd have to assign
> (:-)) it and give a type to it.

Yes.

> Then
> because your types algebra has classes one could create a class of. In the
> end you will face the same question again: what is the assignment on the
> class. All this referential stuff is just shifting subjects.

No, it's not shifting subjects. It's actually what makes it possible
to replace wheels in a car. Or encoding strategies in a string object.

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