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, PLING_QUERY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,329032975b221f1 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1994-10-13 10:28:42 PST Path: bga.com!news.sprintlink.net!hookup!swrinde!howland.reston.ans.net!europa.eng.gtefsd.com!MathWorks.Com!yeshua.marcam.com!charnel.ecst.csuchico.edu!csusac!csus.edu!netcom.com!netcomsv!butch!rapnet.sanders.lockheed.com!rapnet.sanders.lockheed.com!gamache From: gamache@rapnet.sanders.lockheed.com Newsgroups: comp.lang.ada Subject: Re: Q: common types?! Date: 12 Oct 94 12:39:48 -500 Organization: Lockheed Sanders, Inc. Distribution: world Message-ID: <1994Oct12.123948.1@rapnet.sanders.lockheed.com> References: <36c1c0$lve@pong.lasc.lockheed.com> <36taod$3o5@brisbane.celsius.oz.au> NNTP-Posting-Host: dune.sanders.lockheed.com Date: 1994-10-12T12:39:48-05:00 List-Id: Tony Leavitt (tony@deepthought.Sgi.COM) wrote: : I have a question for all you Ada wizards. I do not have a lot of experience : with Ada (only about 3000 lines), and I have begun to start making a common : types package. This package would define all kinds of types for feet, nautical : miles, degrees, radians, etc, ad nuasium, for all different kinds and sizes : of float and integers. Am I about to go insane by trying this? Or, does : this exist already on the Internet somewhere? If I was to attempt to do this : how would you recommend about doing it? : Here is a sample of what I started to do: : : package Common_Types is [snip] I was surprised by the lack of good followups to this post. Now I can't just read the right response, I have to try and write it! Anyway, the short answer is: Yes, you will go insane by trying this. The biggest problem lies not in the part of your example I snipped, but rather the title of your package. Providing implementation independent definitions of the predefined types (as shown in your example) is a good thing. However your chosen packaging literally allows for the rest of the kitchen, including the sink, to be thrown in as well. I strongly believe that this problem, one of packaging misuse, is the largest issue to be confronted on a large development effort. The issue is primarily one of cohesion and coupling which I won't go into here as they can be read about in any decent S/W Eng. text. Consider a different package name such as My_Predefined_Types. It is somewhat obvious that definitions for float_32, float_64, or integer_64 would fit within this package. It should also be clear that types for feet, radians etc. DO NOT FIT within this package! The "Common_Types" package you define will be 'withed' by virtually every package and will also HAVE AN EXCESSIVELY HIGH RATE OF MODIFICATION. That is, today someone on the program needs to add a constant to convert from natical miles to inches, tomorrow someone needs to add a new conversion between degrees and radians. This will go on and on. Since everyone 'withs' this package, everyone will need to be recompiled everytime it changes. This is a form of coupling. This is also disaster. Finally, since there will need to be operations on many of the types you enumerate, your proposed packaging contradicts the state-of-the-art in our discipline, use of object-oriented paradigms (which try to implement twenty year old ideas): In 1972, Parnas wrote, in "On the Criterial to be used in Decomposing Systems into Modules" that in particular, a "data structure, its internal linkings, accessing procedures and modifying procedures are part of a single module." Then in 1975, Liskov and Zilles wrote,a data abstraction is "a group of related functions or operations that act upon a particular class of objects, with the constraint that the behavior of the objects can be observed only by applications of the operations." Thus, if you choose to use the Ada package feature to implement the software engineering concepts it was created for, you would need to include all sorts of operations (subprograms) in an "_types" package. Again, nonesense. My advice is to create your packages top-down and to include all the operations necessary on each package to be consistent with the above quotes. In addition, to allow for easy host/target migration, yes, create a "predefined_types" package that avoids the use of implementation-dependent definitions of integer, float, etc. Finally, for any other "_type" packages that get created (please don't anyone take this post at an extreme, there are exceptions to every rule, and moderation should be the driving force) choose meaningful package names that define a set (as in set theory). This will allow inclusion of types that belong in the package, but more importantly, will keep out types that do not. -------------------------------------------------------------------- with Standard_Disclaimer; use Standard_Disclaimer; --------------------------------------------------------------------