From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,fa2cc518ef3b992c X-Google-Attributes: gid103376,public From: "Vladimir Olensky" Subject: Re: tagged types extensions - language design question Date: 2000/01/31 Message-ID: X-Deja-AN: 579858212 References: <389207CC.C16D80E8@averstar.com> Organization: Posted via Supernews, http://www.supernews.com X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Newsgroups: comp.lang.ada X-Complaints-To: newsabuse@supernews.com Date: 2000-01-31T00:00:00+00:00 List-Id: 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