Re: Seeking for papers about tagged types vs access to subprograms

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

On Wed, 8 May 2013 15:37:24 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:1xlzfj8qy1zey$.up1s1v3syagv.dlg@40tude.net...
>> On Tue, 7 May 2013 15:27:58 -0500, Randy Brukardt wrote:
> ...
>>>> Another problem is that you cannot make everything Controlled without MD.
>>>> Because otherwise you will permanently run into problems with primitive
>>>> operations of multiple types, multi-methods etc.
>>>
>>> Say what? Making everything controlled simply means that every type has a
>>> Finalize operation. Dispatching *within* a Finalize operation is usually a
>>> disaster (you don't want to redispatch as you might be finalizing the parent
>>> part of some child type), so what that has to do with MD is beyond my
>>> comprehension.
>>
>> That is a different issue. I meant that if A and B are controlled/tagged
>> you will have troubles in using them as parameters of same subprogram. Even
>> two parameters of same type is a problem already. Only MD can resolve that.
> 
> That's only a problem if the routine is primitive for *both* types.

There are good arguments for having all parameters either controlled or
else class-wide.

> And 
> that's only a problem if the types are declared in the same package, which 
> is already a bad idea because it means that they have excessive coupling.

The language should prevent operations from being non-primitive, except for
maybe in the package bodies or nested.

>>> I suppose you might get into trouble if you mistakenly try to declare
>>> multiple tagged types in a package, but that's always a bad idea and should
>>> be avoidable in almost all cases (possibly with careful use of limited with).
>>
>> I don't see why is it a bad idea to have related types declared in one
>> package. On the contrary it is a good idea to group related things in a way
>> making it easer to use. I am glad that Ada does not tie types to packages.
> 
> One O-O type per package is the only model that makes sense. It's fine to 
> include "helper" types in the package (stuff like enumerations, integers, 
> and the like), but you should never mix the "big" abstractions of your 
> program. I was never talking about "little" types, like the ones used to 
> interface to hardware -- these should be hidden in bodies anyway. If you 
> can't separate the "big" abstractions, you have too much coupling.

There is no "little" and no "big" types. It is simply wrong to think about
software design in such terms. It was a very bad OO idea to separate types
into "classes" and other types.

An abstraction is always too large for a single type. It cannot be
otherwise.

> Your example of the array index is certainly not the sort of case that I'm 
> talking about; that's a "helper" type and I certainly agree that it's best 
> declared with the array.

There should be no helper types in a properly designed language. Each type
should express/implement something useful from the problem space. Index is
such a thing. There is nothing in it that would make it less important than
the array type, or the array element type.

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