Re: Ada Interfaces and the Liskov Substitution Principle

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

On 1 Cze, 16:53, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> or claiming that there is a semantic difference between X:=Y
> and Assign(X,Y). I don't want a language with magical, semantically
> non-decomposable assignments.

You have them at the level of fundamental types.
You can treat X:=Y and Assign(X,Y) to be equivalent for *your* T (and
if you have complete control over overloading of assignment then that
might be actually the case), but at some level of detail they have to
be implemented in terms of *non-decomposable* assignments of
fundamental types anyway. Now, the difference between T and T'Class is
that operations with T can be statically decomposed down to this non-
decomposable bricks. With T'Class it's just impossible to do this
mechanically and it's unrealistic to expect it from the programmer for
any non-trivial hierarchy.

> > You can replace a Circle with a Triangle but you better not try to
> > assign them.
>
> This is not an explanation. Show a semantic difference between changing a
> name binding from one value to another by A) "replacement" and B)
> "assignment."

No problem. Replacement is when you just stop refering to X and start
refering to Y (or its clone if the objects are mutable). Assignment is
when you decompose down to real, hard-core-metal-and-concrete ':=' on
fundamental types. The difference is that (in Ada terms) replacement
allows you to change the tag. Assignment cannot do this.

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

That's why T'Class, even though very interesting from the language
construction point of view, cannot entirely include all functionality
of access variable to T'Class (or pointer to base class in C++
jargon).

> Then let "assignment" :=
> "replacement,"

Do you mean:
- let's replace assignment by replacement, or
- let's assign replacement to assignment?

;-)

> > No, hierarchies and values don't go together. I might lack the
> > formalism to prove it, but my observations are confirming: I've never
> > seen it in the wild.
>
> Lacking formalism is not an excuse, it is an indictment. (:-))

I don't really think I will ever convince you, but this discussion is
an interesting exercise anyway. ;-)

T'Class should be limited.

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