Re: Ada Interfaces and the Liskov Substitution Principle

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 30 May 2007 00:40:14 -0700, Maciej Sobczak wrote:

> On 29 Maj, 19:07, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
> 
>>> We are talking about real:
>>
>>> X := Y;
>>
>> Huh, how are going to design a non-referential container of T'Class?
> 
> I don't. :-)
> Polymorphism and references come hand in hand if you need the ability
> to reassign. Copy-initialization is the only place where you can
> safely get away with "values" of T'Class.

Are you going to sell me pointers, right here, in c.l.a? (:-))

Referential semantics is an implementation detail. You propose to expose it
to defend a fiction. But it would be in vain, because assigning class-wide
references in this context is semantically equivalent to assigning the
targets.

> I think that the mess has its source in the push to have T'Class
> behaving like normal value.

This is all meta-programming is about: dealing with polymorphic values =
programming in terms of sets of types.

>>> 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.
>>
>> That would be indeed a mess. How would you pass an UTF-8 string to GTK+
>> which knows nothing about your fancy patterns?
> 
> Then it should know.

It cannot, it is ANSI C.

> Otherwise there is no way it can interpret
> correctly what I pass as parameters, unless you want to have
> "implicit" conversions for parameters.

To interpret, to convert etc, all this requires a distinct type. Which is
why different representations have to be mapped to different types.

>> Why don't you use the
>> advantages of the types system?
> 
> I do use it, I just don't elevate implementation details to the level
> of type that is handled directly by the user.

I don't see any handling required. But let it be, then how is it different
from your void * approach? When you create a void * you have to somehow
specify the hidden parameter of the case-statement:

   void * X = Create_UTF8 ("foo");

With types you just specify the type of the object instead:

   X : UTF8_String := "foo";

>>> You can (and should) have dispatching internally in the implementation
>>> of operations of String. I'm not proposing any case statements here!
>>
>> Here you are. What is the difference between internally and externally
>> dispatching assignments?
> 
> Assignment is an operation that is meaningful syntactically - that's
> why it is so tempting. Internally you can have anything else,
> including regular subprogram calls that will do necessary conversions.

But not assignments? The question is how do I do dispatching assignment?
Your point was that I shall not do it publicly. But, may I dispatch
privately? If yes then how? And where is any difference? If not, then the
only way left is a case-statement.

>> Static polymorphism does not allow mixing types.
> 
> ?

Instances from a statically polymorphic class of types are unrelated types.
You cannot have any polymorphic object from that class, only specific
objects. For the same reason you cannot have any class-wide operation from
that class.
 
>> Further you cannot design
>> a library for formatting strings which would not be generic itself.
> 
> 1. So?

Write an editor for such strings, store a string, send it over the network,
do anything after uninstalling the compiler ...

> 2. Yes, I can. Just use arbitrary string type for formatting and then
> convert to the destination type.

Why should I bother to have UTF-8 or ASCII strings if anything is
Wide_..._Wide_Unbounded anyway? What are you going to do if the endianess
of Wide x n Character does not fit your machine?

>> The former is quite possible and IMO is the only right way to go. Note that
>> the language should also allow declaring symmetries of the methods to
>> reduce the number of independent variants.
> 
> Yes, but that reduces the complexity by a constant only, the problem
> is still fundamentally squared.

It is how it is. No matter how you would handle them, you have to all of
them. Whatever pattern you use, you will have to deal with this number of
cases. Do you seriously propose to define some of the cases improperly,
just because there are too many of them? (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de