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 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,23cf9f1e93744eed X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-07-31 15:33:36 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!arclight.uoregon.edu!wn13feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi_feed4!attbi.com!sccrnsc01.POSTED!not-for-mail Message-ID: <3F299920.9070603@attbi.com> From: "Robert I. Eachus" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Need advice re package organization. References: <3F228F3B.9020203@attbi.com> <3F22F9E9.3040307@attbi.com> <5jn9ivoetll1fu2avn9hmjj6aaa7q7pmjn@4ax.com> <9d2Wa.301$jp.253@newsread4.news.pas.earthlink.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit NNTP-Posting-Host: 66.31.71.243 X-Complaints-To: abuse@comcast.net X-Trace: sccrnsc01 1059690811 66.31.71.243 (Thu, 31 Jul 2003 22:33:31 GMT) NNTP-Posting-Date: Thu, 31 Jul 2003 22:33:31 GMT Organization: Comcast Online Date: Thu, 31 Jul 2003 22:33:31 GMT Xref: archiver1.google.com comp.lang.ada:41115 Date: 2003-07-31T22:33:31+00:00 List-Id: Warren W. Gay VE3WWG wrote: > Is this a show stopper? Well, no. But it has been long > recognized in the software industry that information hiding > promotes safety. All I am saying, is that Ada95 seems to > lack this feature and it should perhaps be more vigorously > discussed ;-) If I understand you correctly, what you would like is a syntax for saying that the components of an object can not be modified outside the package hierarchy, but can be read. I can imagine a syntax for doing this, but it wouldn't add any safety. (If nothing else a user could use Unchecked_Conversion to declare a matching type.) But the real problem is what I call unchecked perversion. I coined the name the first time I saw a package specification that contained an instance of Unchecked_Conversion. If a conversion between two types is made public like this, then any code in the entire project can depend on the equivalence, and changing the representation of the type may cause random errors elsewhere in the program. In the case where I first ran into it, it was several conversions between Integer and an access type. Of course, when we went to port the code, some of the access types by default would have used fat pointers. We could force the types to use integer-sized pointers, but it was a pain. The several weeks of work to fix the code would have been a bigger pain. (If I were in the compiler business, I would have a very nasty warning when s package spec contained a visible instance of Unchecked_Conversion.) So the advantage of supplying the inquiry functions is that you can later change the data layout, add new components, change representations, or even make some values which were originally explicit virtual. I think a much better solution to your problem is a tool that automatically generates the inquiry functions from the type declaration. Sounds like a good candidate for adding to the Emacs ada-mode. -- "As far as I'm concerned, war always means failure." -- Jacques Chirac, President of France "As far as France is concerned, you're right." -- Rush Limbaugh