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=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,66253344eaef63db X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,66253344eaef63db X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,66253344eaef63db X-Google-Attributes: gid1108a1,public X-Google-ArrivalTime: 1994-10-01 11:47:21 PST Newsgroups: comp.lang.ada,comp.object,comp.lang.c++ Path: bga.com!news.sprintlink.net!howland.reston.ans.net!agate!ames!enews.sgi.com!wdl1!dst17!mab From: mab@dst17.wdl.loral.com (Mark A Biggar) Subject: Re: Mut. Recurs. in Ada9X w/o Breaking Encaps.? (LONG) Message-ID: <1994Oct1.184319.6665@wdl.loral.com> Sender: news@wdl.loral.com Organization: Loral Western Development Labs References: <1994Sep29.103358@di.epfl.ch> <36eebb$jn5@disunms.epfl.ch> Date: Sat, 1 Oct 1994 18:43:19 GMT Xref: bga.com comp.lang.ada:6364 comp.object:6968 comp.lang.c++:31284 Date: 1994-10-01T18:43:19+00:00 List-Id: In article adam@irvine.com (Adam Beneschan) writes: >I assume that the examples given work correctly. I assume also that >they satisfy the really important requirement--namely, that packages >other than Employee, including Office, have access to everything the >Employee package wishes to put in its interface and to nothing else >having to do with Employees (and similarly for Offices). Thus, this >is certainly an acceptable workaround for the problem. But "clean" >and "elegant"? Maybe I'm being too much of a purist, but I have >trouble characterizing something that requires adding this much code >that has no meaning to someone reading the program, as elegant. It >seems more like a flaw in 9X that things have to be done this way. >And based on my experience writing large Ada 83 programs, my gut >instinct is that this is the sort of flaw that will be cursed by many >9X users down the line. I also realize that if we tried to make Ada >9X absolutely perfect, it wouldn't be Ada 9X any more but something >like Ada 23. :-) It is my understanding that a very early decision in the ada9X revision process was to only add sufficiant new features to Ada to allow development of OOP system using a building block approach. In other words there should be no "One True Way" to OOP in Ada9x. Some of the early ideas proposed for adding OOP to Ada9x would have forced a "One True Way" on the language (E.G., adding package types). Because Ada9x was designed using this building block approach, some things might not end up looking as "Elegant" of "Clean" as in other languages that do have a "One True Way", but the added flexability should make designing OO system that use only as much of the OO stuff as needed very simple compared to "One True Way" system that require you to used everything whether you want it or not. I personally thing that the Ada9x design team has done an excellent job of sticking to the building block approach and have avoided a "One True Way" while providing all the features needed to design OOP systems. -- Mark Biggar mab@wdl.loral.com