Re: Ada Interfaces and the Liskov Substitution Principle

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

On 29 May 2007 08:34:18 -0700, Maciej Sobczak wrote:

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

And for the reason of complexity you drop any compiler support it might
provide you? (:-))
 
>> There are two variants
>> of:
>>
>> 1. Use of T'Class, I considered this in a previous post, it is ambiguous.
> 
> I would ban it. :-)

Sure

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

Huh, how are going to design a non-referential container of T'Class? You
need:

   procedure Insert (..., Element : T'Class) is
   begin
      ...
      Slot := new T'Class'(Element);
   -- Slot := Element; -- in a better Ada
      ...

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

That would be indeed a mess. How would you pass an UTF-8 string to GTK+
which knows nothing about your fancy patterns? Why don't you use the
advantages of the types system? And anyway, let's forget about public
interfaces, if privately it is still one class, then where is a difference?
The only real alternative to classes is a time machine, back to 70s, back
to case-statements. (:-))

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

Here you are. What is the difference between internally and externally
dispatching assignments?

>> And what about fixed vs. bounded vs. unbounded axis?
> 
> This is also interesting, but in a different way. :-)

Why? It is all same: a set of types considered equivalent, hence allowing
cross assignments...

>> Why a fixed string
>> shouldn't be assigned to an unbounded one and reverse?
> 
> Of course it should!

q.e.d.

> What about template methods? ;-)

Static polymorphism is exactly what I am trying to get rid of... (:-))

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

Static polymorphism does not allow mixing types. Further you cannot design
a library for formatting strings which would not be generic itself.
Generics is a dead end.
 
>> 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. ;-)

Surely they have them ... for formatting RM texts. See the difference?
(:-))

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

The latter is what Ada does now, and I agree that this is not Ada (TM).

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. For example, by declaring an
operation commutative.

IMO, multi-methods is not a trick. What I really don't know how to do is
true multiple dispatch (on different types hierarchies). The requirement is
same: dispatch never fails to Constraint_Error.

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