Re: MI is sloppy

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

On Wed, 10 Dec 2008 18:40:46 -0600, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:d0goewygto13.10nsyzpabm3vn.dlg@40tude.net...
>> On Fri, 5 Dec 2008 19:42:40 -0600, Randy Brukardt wrote:
>>
>>> A waste of effort. I don't believe in multiple inheritance (in any form); 
>>> it seems to me to be an excuse for sloppy design.
>>
>> It is like saying that a record with two components is a sloppy design.
>> Either inheritance is a rubbish concept or else it is multiple.
>>
>> My pet example of MI is:
>>
>>   type In_File is ...;
>>   procedure Get (File : in out Input_File; Item : out Data);
>>
>>   type Out_File is ...;
>>   procedure Put (File : in out Output_File; Item : Data);
>>
>>   type Inout_File is .. ?
>>
>> Is it sloppy?
> 
> I tend to think so. These are insufficiently different to be types; there 
> should only be one type and different subtypes. Subtypes imply runtime 
> checks, but with good contracts most such errors can still be detected by 
> tools. And you don't have the goofy restrictions that come with trying to 
> make things separate types that aren't logically separate.

Huh, I don't see any difference. Semantically

   type Inout_File is ...
   procedure Get (File : in out Inout_File; Item : out Data);
   procedure Put (File : in out Inout_File; Item : Data);

   subtype In_File is ...;
   procedure Get (File : in out Input_File; Item : out Data) is abstract;

   subtype Out_File is ...;
   procedure Put (File : in out Output_File; Item : Data) is abstract;

Whatever way you go, incrementally adding operations or else incrementally
removing them.

But the second is certainly worse because it is statically uncheckable, it
is a "God-class," it is potentially inefficient when only input is used,
etc. (It is not the way programs are designed, if we could pick a ready
program from the pool of all possible programs. (:-))

> This is very much like the attempt to statically check accessibility 
> (lifetime) of objects. It doesn't work, at least not in general. And we have 
> much better technology in terms of detecting errors without goofy 
> restrictions than we did when these rules were defined, so why not use 
> them??

I just do not believe that. IF there is a tool capable to read my mind and
understand the program semantics and the reasonably warn me, THEN, please,
build it into the compiler and make those warnings errors. If there is
something (badly wrong) with that, then I don't need neither this tool nor
its features in the compiler.

Tools is cancer of compilers.

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