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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,e6622c2c0e563df2 X-Google-Attributes: gid103376,public From: Andre Spiegel Subject: Re: Standard library and distributed systems Date: 1997/07/02 Message-ID: #1/1 X-Deja-AN: 254076778 Sender: spiegel@moon References: Organization: Freie Universitaet Berlin X-Access: 16 17 19 Newsgroups: comp.lang.ada Date: 1997-07-02T00:00:00+00:00 List-Id: Samuel Tardieu writes: > Andre, I agree with most of your points, but I really wonder why you > want *so hard* to make these packages Remote_Types? Why don't you > define your own types in such a package? You have shown in your > multiple posts that it was not possible to use bounded and unbounded > strings as defined by the Annex A as remote types without changing > some standard's library specifications. This looks like a blocking > problem for you, and that I cannot understand. Sorry, I didn't intend to become a nuisance ;-). I only repeated my question because I didn't get any answers at all. And I did post to the newsgroup because I saw my own question asked by somebody else here, so it seems that I'm not the only person who considers the above problem as a, well, "unfortunate" restriction. Besides, I do think it's an important issue. The features of Annex E achieve a very high degree of distribution transparency -- Ada is much better than other existing technologies like Java/RMI or CORBA in this respect. This allows you to develop applications without thinking about distribution issues until very late in the development process. Given this high transparency, one could also distribute existing, non-distributed applications with very little or no changes to the code. Bounded_String and Unbounded_String are very important types that some programmers use all over the place. But in the current form of the library, that means you cannot distribute such programs (or components). This is odd. Especially if it could be achieved easily -- and this is how it appears to me. Sure I could write my own replacements for those packages. But that seems only a second-best guess if all that's required is a slight change to the standard library that many other programmers would also benefit from. Finally, if my impression is correct that the language rules are overly restrictive in this area, that is a lack of transparency which will also affect the distributability of other programs and components, not just those in the standard library. It may not be realistic to aim at 100 percent transparency -- but I wouldn't be satisfied if, while writing a program, I had to think about distributability all the time because Annex E is so restrictive. As far as I understand it, this is not the way it was meant to be.