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,fa2cc518ef3b992c X-Google-Attributes: gid103376,public From: Tucker Taft Subject: Re: tagged types extensions - language design question Date: 2000/01/28 Message-ID: <389207CC.C16D80E8@averstar.com>#1/1 X-Deja-AN: 578915989 Content-Transfer-Encoding: 7bit References: X-Accept-Language: en Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@inmet2.burl.averstar.com X-Trace: inmet2.burl.averstar.com 949094348 1288 141.199.8.164 (28 Jan 2000 21:19:08 GMT) Organization: AverStar (formerly Intermetrics) Burlington, MA USA Mime-Version: 1.0 NNTP-Posting-Date: 28 Jan 2000 21:19:08 GMT Newsgroups: comp.lang.ada Date: 2000-01-28T21:19:08+00:00 List-Id: 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. When designing a language there are hundreds of tradeoffs. We chose a "building block" approach to Ada 95. Rather than trying to anticipate all uses, and make every feature have several bells and whistles, we tried to provide features that can be combined in an infinite number of ways to solve whatever problems are encountered. In general, if you start comparing languages, you are working in the "solution" space rather than the "problem" space, and you will generally be frustrated if you try to find an exact match in the solution space. The more important issue is whether you can solve the problems of interest efficiently and effectively using the features of the language you are evaluating. 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. In some of the problems I have seen, a natural solution in Ada is to implement the abstraction with a fully public record type, but make certain components of the record be of a private type. More often, I have found it better to implement the abstraction using a fully private type, and then add set/get operations as needed to expose certain components where appropriate. Quite often I end up discovering that either the "set" or "get" ends up requiring more than a simple assignment or load from the corresponding component of the underlying record, and I congratulate myself for having the "foresight" (yeah, right) to use a fully-private type in the first place. 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... > Regards, > Vladimir Olensky -- -Tucker Taft stt@averstar.com http://www.averstar.com/~stt/ Technical Director, Distributed IT Solutions (www.averstar.com/tools) AverStar (formerly Intermetrics, Inc.) Burlington, MA USA