Re: A bad counterintuitive behaviour of Ada about OO

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

On Fri, 08 Aug 2014 15:53:52 +0200, J-P. Rosen wrote:

> Le 08/08/2014 15:11, Dmitry A. Kazakov a écrit :
>>> Yes of course, but the /theory/ of it, and especially group theory etc.
>>> that you mentioned is not a programmer's concern.
>> 
>> How so? If integer is not ordered there is no "<" defined, if there is no
>> "<" how are you going to have an ordered map with integer keys?
> Well, of course the computer Integer has "<", but to use it I don't need
> to know (nor do I give a damn) that it is a group, and that other types
> are also groups.

The question was about maps. Should maps be restricted strictly integer
keys?

>>> A generic can be applied to types that are not related in any way.
>> 
>> They are related in exactly the way that this generic can be applied to
>> them. Is the feature of being applicable in a generic relevant for
>> programmers? I think it is. 
> The point is that of logical dependency. If I have a type T, and want to
> use an operation defined on class C, I have to make my type a member of
> C. And C has other members, that become somehow the brothers of T. LSP
> means that they can be interchanged in some situations.

So are formal generic types. They are somehow brothers and they can be
interchanged in instantiations. You can instantiate a generic with one type
or another.

> Now, you can define the "class of all types that can instantiate G".
> Possible, but useless.

And having a useless class makes an advantage over having a useful class? I
don't understand the logic.
 
>>> This reminds me of a (bad) example of inheritance I once saw in a book:
>>> the class "parrot" inherited from the class "human" because it needed
>>> the method "can_speak". I'm somewhat uncomfortable with the notion that
>>> a parrot is a special kind of human ;-). Well, it's a bad example
>>> because inheritance should not be used just to grab any method you need.
>> 
>> It is bad design, because the class of things that can speak is not the
>> class of humans. Parrots and humans certainly participate in some classes,
>> e.g. in Chordates, Tetrapoda etc.
> The point is that often people write a method on a class, and then
> inherit from it because they want to reuse a method.

While you don't want to reuse any operations defined in a generic package.
People put operations into generic packages out feeling of pure joy. No bad
intentions to reuse them anyhow. Is that your point?

>> There is
>> tight relationship between operations =, /=, <, >, >=, <=, 'Prev, 'Next of
>> an ordered set. This is what makes it such a thing. Inheriting to Ordered
>> tells to the reader all this in just one source line. Moreover, it allows
>> the compiler to check if the manifested type is indeed ordered and even
>> prove some of this like x=y <=> not x/=y. 
> Certainly not. Inheriting from Ordered guarantees that all these
> operations are available, but say nothing about the semantics. If you
> want to add semantics, use type invariants and the like.

Sure I can. And I can reuse Ordered interface in other places, probably put
it into the standard library. And programmers can accustom to it as they
are to built-in scalar types.

>> Compare this with generics. They
>> just name some operations and the programmer should guess about the purpose
>> of what the actual type should be. Yes there is no dependency ... on the
>> application domain. Just an ad-hoc mess.
>> 
> It's not a mess. It's generality. The actual type should be anything
> that matches the contract.

The "contract" is a mess. It is not much better than C++ template
"contract," anything that passes compilation is OK. Contracts must be
verifiable, have predictable consequences, recognizable from the
application domain.

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