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.7 required=5.0 tests=BAYES_00,INVALID_DATE, MSGID_SHORT,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!ncrlnk!ncrcae!hubcap!billwolf%hazel.cs.clemson.edu From: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) Newsgroups: comp.lang.ada Subject: Re: Modernizing Ada Message-ID: <6780@hubcap.clemson.edu> Date: 14 Oct 89 20:50:34 GMT References: <8910132028.AA07013@helios.enea.se> Sender: news@hubcap.clemson.edu Reply-To: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu List-Id: >From sommar@enea.se (Erland Sommarskog): > My issue is the langauge definition. The inheritance mechanism > should integrated with existing constructs in Ada. Say that you add > classes a new compilation unit to Ada. Easy? Yes, but why then > keep packages? OK, make the classes package types, but somehow > I feel that we will ending up having something in the langauge > that will be obsolete once we have a inheritance mechanism, multiple > or not. Actually, there are a lot of things which seem "scattered" when one starts thinking about expressing even user-defined types in Ada, regardless of whether inheritance is present or not. For example, currently the language defines attributes for predefined types, and implementations may also define attributes, but a user-defined type can't define its own attributes. The result is that one has to use operations over the type to do "synthetic" attributes. But now we have an inconsistency: for the predefined types we can use the attribute notation (which is actually rather common in object-oriented languages), and all is well. But for the "synthetic" attributes, we must use the subprogram call notation. Why is there this scattering of the attribute concept across the syntax for attributes and the syntax for subprograms? For its time, Ada was an outstanding design, but it seems that the object-oriented concepts were still a little fuzzy and not completely integrated. Properly integrating the various constructs would result in a clean, crisp 9X which will not be subject to the great criticisms of excessive complexity which have plagued Ada 83; if this is done, 9X will be a heck of a lot easier to learn (and adopt) than 83 was. Jean Ichbiah, in "Ada: Past, Present, Future" (CACM, October 1984) commented on the criticism of excessive complexity that regardless of the number of details, complexity depends upon "whether or not it is easy to infer the details from major structural lines"; quite true, but there is some simplification and integration that could be done with these structural lines to make a cleaner product. IMHO, it is probably possible to add multiple inheritance to Ada without cleaning up what in certain areas is a fragmented design, just as it is possible to let that original fragmentation persist. However, the results won't be pretty, and we have an opportunity before us to correct errors of commission as well as of omission. More importantly, though, it will demonstrate Ada's will to survive. COBOL, had it been willing to update itself properly, would over time have turned into what Ada is today (more or less); believe it or not, COBOL started out (Ichbiah, CACM, Oct. 84) with "exactly the same" motives that Ada started with!! Because of COBOL's demonstrated inability to change with the times, the DoD decided to just scrap COBOL completely and start over. I would hope that this fate is not in store for Ada as well. We already are going to have to solve substantial problems with the tasking model, handle the impact of asynchronous exceptions, etc., and there is enough change needed already to ensure that we have every incentive to act now. As long as progress continues to be made in software engineering technology, we cannot stand still. Our inertia must always be a *forward* inertia -- the tendency to keep advancing. Bill Wolfe, wtwolfe@hubcap.clemson.edu