Re: MI is sloppy

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

On Sat, 06 Dec 2008 18:16:37 +0100, Georg Bauhaus wrote:

> Dmitry A. Kazakov wrote:
> 
>>    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 .. ?
> 
> OK, I can use an object of type Inout_File both as In_File or
> as Out_File.  OTOH, I'm unsure about the notion of Inout_File.

Look at Ada's standard subtypes called "modes." Each Ada type (except
anonymous access) has all of them: "in", "out", "inout", and "constant"
which is merely another name for "in".

> Similarly, is it proper design to make a two-way street appear to
> have only one polymorphic lane, i.e. think of streets as objects of
> a single MI type? I wouldn't want to drive there unless a big, proven
> apparatus of typing machinery, calling protocol, etc. makes sure
> that my car won't be driving along the wrong view of the street.
> I'm not sure but this seems like overhead to me. (Yes, I know there
> are cabins and speed trains and normal trains being directed this
> way. Without MI AFAIK, so I wonder how rail-bound traffic control
> could profit from MI. Will there have to be additional contracts
> for MI type that establish a proper order of object use?)

OK, make the following experiment. Go outside and look at the left side of
the roadway. Cross it to the right side and then turn around 180 degrees.
Study it. Can you note any difference? There is no one! A big advantage,
you know. You don't need another car, another driving license etc in order
to be able to drive back home. In SW we call it reuse. MI is nothing but
reuse.
 
> Can't we just make Inout_File some composition and hide the details
> completely, behind a suitable collection of primitive operations?

A hidden composition does not exist for observers <=> it does not exist at
all. But if you wanted to argue for MI of interfaces (Ada 2005) with an
aggregation behind the scenes, then that obviously would not work. The
diamond diagram is a counterexample:

   type Abstract_File is ...;
   procedure Name (File : Abstract_File) return String;

   type In_File is new Abstract_File ...;
   procedure Get (File : in out Input_File; Item : out Data);
 
   type Out_File is new Abstract_File ...;
   procedure Put (File : in out Output_File; Item : Data);

   type Inout_File is .. ?

No way.

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