Re: Ada Interfaces and the Liskov Substitution Principle

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

On 29 May 2007 01:03:23 -0700, Maciej Sobczak wrote:

> On 27 Maj, 12:04, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
> 
>> To ban something in the language you have to translate the ban into
>> language terms. That could be either by syntax or by semantic rules.
>> Because syntactically banned assignments are indistinguishable from legal
>> ones, the only mechanics you could use for this is matching types. The
>> types in question are from the same hierarchy (covariant). This lets mixing
>> such types. So it *must* be contravariant to be banned = the operation
>> (":=") will not be inherited in the argument of interest upon inheritance.
> 
> 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. There are two variants
of:

1. Use of T'Class, I considered this in a previous post, it is ambiguous.

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

>> 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. Character encoding can/should be a strategy
> inside a String, you don't need to subclass the whole thing just for
> it. There are many aspects on which you could parameterize String and
> with some of them being orthogonal you could quickly end up with
> milion leaf classes.

So? This is exactly the reason why I want to keep them all in one class.
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.

And what about fixed vs. bounded vs. unbounded axis? Why a fixed string
shouldn't be assigned to an unbounded one and reverse? How are you going to
design such stuff without polymorphism? By cut'n'paste, as RM does? At some
point they too had got tired:

"... For each of the packages Strings.Fixed, Strings.Bounded,
Strings.Unbounded, and Strings.Maps.Constants the corresponding wide string
package has the same contents except that 

� Wide_Space replaces Space 

� Wide_Character replaces Character 

� Wide_String replaces String ..." (:-))

>> The very definition of a class says that types there share class-wide and
>> primitive operations. If that is not the case: ":=" is not shared, then
>> either it is not a class (= don't derive! if need not) or there is no ":="
>> (= make it limited! if unsure). Looks much like a design problem.
> 
> Yes. That's why I say that I have never seen any reasonable hierarchy
> that supports assignments.

Strings above.

>> There is nothing special in
>> assignments.
> 
> Yes, there is - they are generated. This is deceptive, because it
> makes one think that it should all work by magic.

It means that the language is unable to express assignments in its own
terms. I don't want such language. In fact, the rules you propose for
assignments can be expressed in Ada terms:

type X is private;
type Y is new Y;  -- Done

Don't use classes if you don't want to assign them.

> 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. The
only problem Ada has with assignment is that it is a fake MD. If it were a
true MD, then upon inheritance (per extension) from a tagged private T, the
compiler would complain: "hey, I don't know how to assign T to S!" This
would force you to override S := T in a reasonable way (existing for
String) or else to rethink your allegedly wrong design. Presently Ada
silently generates raise Constraint_Error, which is not good.

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