Re: Ada Interfaces and the Liskov Substitution Principle

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

On 29 Maj, 15:18, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> > OK, now I see your point. I have nothing against following this path -
> > assignment statement *is* special anyway. What could go wrong if we
> > say that assignment is not inherited?
>
> Then you will have a messy bunch of overloaded ones.

If I need them and can reasonably implement them, yes.
The design complexity of this will be somewhere there anyway.

> There are two variants
> of:
>
> 1. Use of T'Class, I considered this in a previous post, it is ambiguous.

I would ban it. :-)

> 2. Non-primitive operation (ugly hack). This will not work on class-wide
> arguments:
>
>    X : T'Class := Y; -- Illegal, ":=" isn't defined on LHS T'Class

This is not assignment_statement. This is initialization and I have
nothing against it. Actually, it is no different from initialization
of subprogram parameters and as such is not only harmless, it is
essential.

We are talking about real:

X := Y;

:-)

> >> And I don't see why it is a mess. What is wrong in assignment of
> >> UTF8_String to Wide_String, both from String'Class?
>
> > Probably design issue.
[...]
> So? This is exactly the reason why I want to keep them all in one class.

That's what I'm talking about (but then, we might be using different
terminology).
I say that you need one type String, that possibly uses strategy
internally to delegate details like encoding. You don't need encoding
to "leak out" at the level of types that the final user operates on.

> Encoding is a constraint put on the object. It is mapped to a type to be
> able to implement string operations independently, for each encoding
> through dispatching rather than by ugly nested case-statements.

You can (and should) have dispatching internally in the implementation
of operations of String. I'm not proposing any case statements here!

> And what about fixed vs. bounded vs. unbounded axis?

This is also interesting, but in a different way. :-)
Treating everything in pure OO way, these might be again internal
strategies of a single String type. Think of stream buffers in streams
(C++, Java).
On the other hand, purity is not always beneficial and from the
performance point of view fixed string provides the opportunity to get
rid of dynamic allocation. But to benefit from this opportunity, you'd
better not mess with OO but distinguish them using compile-time
polymorphism. In C++ we have policy-based class design for it.

> Why a fixed string
> shouldn't be assigned to an unbounded one and reverse?

Of course it should! What about template methods? ;-)
(hint: constructors and assignments in STL containers are templated
exactly to allow freedom in this aspect)

> How are you going to
> design such stuff without polymorphism?

Compile-time polymorphism works just fine and if you really need run-
time parameterization, you can get it with internal strategies (again,
think streambuf in streams in C++).

> By cut'n'paste, as RM does? At some
> point they too had got tired:
[...]

Yes, I have noticed. :-)
Looks like you guys need *real* templates. ;-)

> > Another reason why they are special is that they are intuitively
> > associated with some particular effects and these effects cannot be
> > reasonably provided in an automated way. That's why I think that
> > assignments of class-wide types should be forbidden.
>
> No, it is much simpler to provide multi-methods and make it consistent.

But then the compiler would need to either force you to implement the
whole square of assignment operations, or use run-time checks to
discover whether the assignment within a given pair of leaf types is
provided.
The former is unrealistic with evolving or open-ended hierarchies, the
latter smells more like Python than Ada.

> Presently Ada
> silently generates raise Constraint_Error, which is not good.

Agreed.

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