Re: tagged types extensions - language design question

["Vladimir Olensky" <vladimir_olensky@yahoo.com>]

Tucker Taft wrote in message <389207CC.C16D80E8@averstar.com>...
>Vladimir Olensky wrote:
>>
>> The question is :
>>
>>    Why in Ada it is  not allowed to extend both public
>>  and private part of the tagged type at one step ( using
>>  kind of syntax as in the following example ):
>> ...
>>     It would be interesting to know what were
>> the reasons not to allow to have BOTH a record
>> extension AND a private extension at the same time.

-------------------
> I suppose the ultimate answer is that the need for a partly private/
>partly visible abstraction was thought to be rare enough that it
>was felt to be better to keep the set of language primitives simpler, and
>allow the programmer to combine them as needed to handle the more
>complicated problems.  As usual, your mileage may vary...

>Personally, I would be more interested in real-world examples
>of problems that in some sense require an abstraction whose
>implementation is partly private and partly visible.

Below is my example:

Having  now  some spare time I started to  create general
purpose communication subsystem for WinNT which gives
it's users unified access to any communication tool/device.
So far everything regarding communications is scattered
around in WinAPIs and I know only one implementation of such
high-level communication class library and this is Adaptive
Communication Environment -ACE created by Doug Schmidt.
This is very good one but  it is written entirely in C++.

I decided to create  Ada based communication  subsystem
using more  simple and traditional approach  how to combine
everything in one communication class library that provides
unified access to any needed mean of communication
regardless of it's nature (serial communications, parallel
communications, USB, pipes, mailslots, memory mapped files,
sockets  and any other device/tool that may appear later).

All these communication "bricks" could allow quickly build any
control application that needs easy communication between it's
loosely coupled parts that could work on the same machine or on
the different ones.
This allows to use more lightweighted and easy approach  than
CORBA.  On the other hand  higher level abstractions (as used
in ACE ) could be easily built  using  such general purpose
communication library.

This idea was eating me for quite some time  not allowing me
to concentrate on some other interesting things so I felt that it is
time to give it it's way out.  Now it is beginning  to take shape.

I started with Win IPC and implemented memory mapped files,
mailslots, named pipes (only sync mode so far). And this library
will grow with the time.

My design model is as follows:

Any mean of communication could be considered as communication
controller  that handles underlying communication device.
Controller  provides standard set of operations for the client and
translation of these commands into  low level  communication device
primitives. Communication  device handles communication on
the physical level.  In this model communication device can be
considered as set of correspondent   OS or driver  API calls or
as direct device implementation as in case of memory mapped
files (it does not really matter ).

On the other hand in  any communication process there are two sides.
One is a Server process and the other is a Client process. Or in the
communication  terms one side is DTE and the other is DCE.
DTE/DCE corresponds not only to the physical ports but also to the
logical  role of each side ( e.g in X.25 or Frame Relay two stations
can communicate with each other  having direct connection of DTI
physical ports where one side plays logical DCE role and the other is
logical DTE role).

What's interesting there is nothing new in all that. This is a standard way
to build communication systems hardware and software  but surprisingly
this approach is rarely used in design of most of the operating systems
user libraries  and  in software development systems. At least Java
libraries come  close to that in some extent.
I know only one system which  has  clever implementation of that model.
This is a communication subsystem of  OS/400 for IBM AS/400 midframe.
May be there exist others but I do not know.

According to this model I have abstract  communication controller root type
which is Limited_Controlled type (RHT) with private part  and set of
standard  non abstract communication primitives  - Open,Close,Read,
Write,  Peek,  Get_Controller_State,  Get_Device_State,  Get_Config,
Set_Config, Initialize  etc.

There are two kinds of operations in a root package:

1. first type is primitive RHT operations :

  procedure Op (hComm: in out RHT) is
   begin
       raise Not_Implemented;
   end   Op;

2. the others are  class wide operations

  procedure Op (hComm_Ref : in out RHT_Ref_Type) is
   begin
       Op (hComm.all);
   end   Op;

   where RHT_Ref_Type is access all RHT'Class;


Each concrete controller and it's underlying device are initialized
implicitly by  creating the  instance of particular controller:

sPipe         : Server_Named_Pipe;
sPipe_Ref : Server_Named_Pipe_Ref_Type := new Server_Named_Pipe;

and then one can  use any of the standard communication  controller
primitives.

So far everything is OK.

Problem arise when we come to the run time communication device
properties that we do not know in advance.

The idea of the communication controller is that all the communication
primitives are defined at the top level and we do not want to break this
model by adding some new operations later (may be only some very
limited number).

But on the other hand for some of the communication devices we should
allow client to know some of the low level device properties ( view access)
to take some client dependant decisions ( One of the examples is
simplex communication of two applications via memory mapped file  or
async operational mode where one may want to know the state of related
events for the particular device ) .
This means that these properties should have public access.
First I did that as a separate (from the controller)  Device Property Record
type defined in each concrete device controller package but then I come
to conclusion  that this is bad  approach as all  the information about
device should be contained in the device controller  and be available
to the controller client only via this device controller interface.  There
are also some other things that makes first approach (with separate
RT property record variable) very inflexible.

As a result of that I moved these run time device properties record into
controller record  as a Device_RT_Properties  record entry (with public
view ).

At this point I found that I could not extend both public and private part
of the tagged type in one step and that's why I asked my question - why
it not allowed in Ada  to extend both public and private part in one step.

Another question regarding this issue is how can I make this properties
to have read only access for clients and read-write access internally
without any low level unchecked programming. The last one is easy but
it is always better to avoid any low level tricks.

As a matter of fact I started all these as Windows NT communication
subsystem  and called it as WinCMN.

Actually this is some kind of universal approach and that unified
communication interface could be used to access any communication
resources in any other operating system and be a kind of  general
purpose Ada class library ( for any OS)  that allows to dynamically
create, deallocate, use, insert that controllers in chains/lists , query
available communication resources  etc.

May be it is worth until it is not too late to change the  name of the root
package  to  ACMN and  have OS dependant child  packages named
after each OS  ( e.g. ACMN.Win  - for WinNT communication subsystem,
ACMN.Linux - for Linux,  ACMN.NR_OS - for Nick Roberts AdaOS  etc.) ???

I have now only three concrete controller classes and it is not very
difficult to change naming  scheme at this moment.

Regards,
Vladimir Olensky