* Package reformatting tool availability @ 1999-09-03 0:00 Andy Askey 1999-09-03 0:00 ` Robert Dewar ` (2 more replies) 0 siblings, 3 replies; 9+ messages in thread From: Andy Askey @ 1999-09-03 0:00 UTC (permalink / raw) Hello, I have several Ada legacy packages that contain multiple types. I prefer that each type is in its own package/file for my Ada95 development effort. Does anyone have (or know of) a script or other tool that will turn a package with multiple types into multiple packages with one type? Thanx. -- --------------------------------------------------- | Andy Askey | | Software Engineer | | Raytheon Systems Company | | 670 Discovery Drive, Huntsville, AL 35806 | | Phone: (256) 971-2367 Fax: (256) 971-2306 | | andrew_j_askey@res.raytheon.com | --------------------------------------------------- ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Package reformatting tool availability 1999-09-03 0:00 Package reformatting tool availability Andy Askey @ 1999-09-03 0:00 ` Robert Dewar 1999-09-07 0:00 ` Andy Askey 1999-09-03 0:00 ` Robert Dewar 1999-09-06 0:00 ` Pierre Dissaux 2 siblings, 1 reply; 9+ messages in thread From: Robert Dewar @ 1999-09-03 0:00 UTC (permalink / raw) In article <37CFFA58.FFC67480@res.raytheon.com>, Andy Askey <askeya@res.raytheon.com> wrote: > Hello, > > I have several Ada legacy packages that contain multiple types. I > prefer that each type is in its own package/file for my Ada95 > development effort. Does anyone have (or know of) a script or other > tool that will turn a package with multiple types into multiple packages > with one type? I do not know of such a package, and it would be a bit of a suprise if one existed, because the goal here is not a generally desirable one. Insisting that each type be in its own package as a general rule is definitely shooting yourself in the foot. Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Package reformatting tool availability 1999-09-03 0:00 ` Robert Dewar @ 1999-09-07 0:00 ` Andy Askey 1999-09-08 0:00 ` Robert Dewar 1999-09-11 0:00 ` Richard D Riehle 0 siblings, 2 replies; 9+ messages in thread From: Andy Askey @ 1999-09-07 0:00 UTC (permalink / raw) Thanx for the info. I noticed from the responses here (and others emailed) that the everyone wanted to know why I would need this tool since packages are meant to contain only related types and therefore should not be broken up. Unfortunately the legacy Ada I have dealt with in the passed 7 years has a different criteria for grouping types within packages. It appears that there is some rule of thumb that only about 30-50 types can be placed in one package. When more types are created, there is an obvious need for another package. I guess this makes it easier on the developers. Some discipline of thought must be that the number of "with" statements increase complexity exponentially. I missed this course in school and must fall back on the "related types to a package" philosophy. Therefore, I have a need for this tool to bridge this software philosophical chasm. Actually, I figured out the requirements of what I need. Maybe I'll get bored some weekend and write a perl script break up packages based on dependency relationships. I'll post this if I do ... but then again, football season just started. Andy -- --------------------------------------------------- | Andy Askey | | Software Engineer | | Raytheon Systems Company | | 670 Discovery Drive, Huntsville, AL 35806 | | Phone: (256) 971-2367 Fax: (256) 971-2306 | | andrew_j_askey@res.raytheon.com | --------------------------------------------------- ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Package reformatting tool availability 1999-09-07 0:00 ` Andy Askey @ 1999-09-08 0:00 ` Robert Dewar 1999-09-11 0:00 ` Richard D Riehle 1 sibling, 0 replies; 9+ messages in thread From: Robert Dewar @ 1999-09-08 0:00 UTC (permalink / raw) In article <37D542F9.3C6C9F4D@res.raytheon.com>, Andy Askey <askeya@res.raytheon.com> wrote: > Thanx for the info. I noticed from the responses here (and others > emailed) that the everyone wanted to know why I would need this tool > since packages are meant to contain only related types and therefore > should not be broken up. OK, a tool to break things up so only related types end up in a given package makes MUCH more sense :-) Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Package reformatting tool availability 1999-09-07 0:00 ` Andy Askey 1999-09-08 0:00 ` Robert Dewar @ 1999-09-11 0:00 ` Richard D Riehle 1999-09-13 0:00 ` Robert Dewar 1999-09-14 0:00 ` Mark Lundquist 1 sibling, 2 replies; 9+ messages in thread From: Richard D Riehle @ 1999-09-11 0:00 UTC (permalink / raw) In article <37D542F9.3C6C9F4D@res.raytheon.com>, Andy Askey <askeya@res.raytheon.com> wrote: >a different criteria for grouping types within packages. It appears >that there is some rule of thumb that only about 30-50 types can be >placed in one package. When more types are created, there is an obvious >need for another package. Yikes!!!!!! Fifty types per package? Therein lies a uparalleled opportunity for keeping maintenance programmers secure in their jobs for a very long time. It reminds me of the COBOL programmer who creates a package Data_Division, the Fortran programmer with a package Common, or the Jovial/CMS-2 programmer with package Compool. One of the problems with the Ada package is how it encourages such practices. This reflects one of the benefits of C++ or Eiffel: each C++ class is a type. If I still understand object-oriented modeling, a package should export one main type with appropriate operations on that type. The structure of the type is hidden from a client of the package. The package may also export some supplementary types such as enumeration types, etc. Does this create too many packages? What is too many? Robert Dewar is fond of reminding us that Ada is designed to be more readable than writeable. That is one of goals of encapsulation and information hiding, isn't it? I thought Brad Balfour and Ed Seidiwitz long ago put the issue of global Ada type packages to rest. Also, with the advent of generic formal package parameters, child library units, private child units, and the new renaming options, Ada 95 makes it easy to design small packages that support the behavior of one type In fact, used correctly, these features of Ada 95 put Ada ahead of some other languages such as C++ where type <=> module <=> class. Brad. Where are you when we need you? :-) Richard Riehle http://www.adaworks.com ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Package reformatting tool availability 1999-09-11 0:00 ` Richard D Riehle @ 1999-09-13 0:00 ` Robert Dewar 1999-09-14 0:00 ` Mark Lundquist 1 sibling, 0 replies; 9+ messages in thread From: Robert Dewar @ 1999-09-13 0:00 UTC (permalink / raw) In article <7ree14$t3h@dfw-ixnews6.ix.netcom.com>, Richard D Riehle <laoXhai@ix.netcom.com> wrote: > Yikes!!!!!! Fifty types per package? Therein lies a uparalleled > opportunity for keeping maintenance programmers secure in their jobs > for a very long time. Hmmm! I don't like even *suggesting* that a simple numeric criterion is appropriate. Two is too many if the types are unrelated and would be better off in separate packages. Fifty or more may be fine if they are somehow a coherent set of related types. Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Package reformatting tool availability 1999-09-11 0:00 ` Richard D Riehle 1999-09-13 0:00 ` Robert Dewar @ 1999-09-14 0:00 ` Mark Lundquist 1 sibling, 0 replies; 9+ messages in thread From: Mark Lundquist @ 1999-09-14 0:00 UTC (permalink / raw) Richard D Riehle wrote: > In article <37D542F9.3C6C9F4D@res.raytheon.com>, > Andy Askey <askeya@res.raytheon.com> wrote: > > >a different criteria for grouping types within packages. It appears > >that there is some rule of thumb that only about 30-50 types can be > >placed in one package. When more types are created, there is an obvious > >need for another package. > > One of the problems with the Ada package is how it encourages such > practices. I wouldn't agree that Ada "encourages" this. Ada allows it. So does C++. You can define any number of classes is in a file, as many as you like (similarly, a Java package can contain arbitrary class definitions). While packages may seem to contain primitives in the same sense that classes contain member functions, the C++ analogue of a package is not a class. If anything, the (poor) C++ analogue of an Ada package is the "file", as in ("header file" and "implementation file"). There is another aspect in which the analogue of the Ada package is the C++ namespace. > This reflects one of the benefits of C++ or Eiffel: each > C++ class is a type. That's more of a definition than a statement, so I'm not getting what the benefits are... > If I still understand object-oriented modeling, a > package should export one main type with appropriate operations on that > type. The structure of the type is hidden from a client of the package. > The package may also export some supplementary types such as enumeration > types, etc. > > Does this create too many packages? What is too many? Robert Dewar > is fond of reminding us that Ada is designed to be more readable than > writeable. That is one of goals of encapsulation and information hiding, > isn't it? Actually, I would say not. The goals of encapsulation have to do with abstraction (and whether abstraction leads to greater readability is sort of in the eye of the beholder, and it involves lifecycle considerations too). Readability is the goal of clean syntax. > I thought Brad Balfour and Ed Seidiwitz long ago put the issue > of global Ada type packages to rest. > > Also, with the advent of generic formal package parameters, child library > units, private child units, and the new renaming options, Ada 95 makes > it easy to design small packages that support the behavior of one type > In fact, used correctly, these features of Ada 95 put Ada ahead of some > other languages such as C++ where type <=> module <=> class. > I'd say Ada95 is ahead even without considering those features, but...:-) Are you saying that Ada's separation of typing and modularity is a weakness (as you seemed to be saying earlier), but that this weakness is overcome by the correct use of certain other features? I believe that the conflation of type and module into one construct is a mistake -- unfortunately, that's the "idea package" in which most of us (myself included) first encountered OO, thanks to Alan Kay and Adele Goldberg. At the time, this idea was a great experiment (not the only great experiment of the Smalltalk environment, of course -- the other was the window-mouse MMI paradigm). And paradoxically, it was necessary that OO hit the streets in the radicalized, class-oriented form, because the computing community really did need to have its collective brain washed in order to understand and accept the value of the underlying, true OO concepts (encapsulation, inheritance, polymorphism, and for all but the most extreme "purist", genericity). But the attempt to fundamentally define and forumulate OO in terms of the class construct is moribund. I've been wanting to write an article about the myth of "pure OO" and the brokenness of class-centered OO... just haven't been able to make the time to do it. Plus, I don't know if the world is ready... :-) :-) -- Mark Lundquist Senior Software Engineer Rational Software Development Solutions Business Unit UNIX Suites Group Aloha, OR, USA ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Package reformatting tool availability 1999-09-03 0:00 Package reformatting tool availability Andy Askey 1999-09-03 0:00 ` Robert Dewar @ 1999-09-03 0:00 ` Robert Dewar 1999-09-06 0:00 ` Pierre Dissaux 2 siblings, 0 replies; 9+ messages in thread From: Robert Dewar @ 1999-09-03 0:00 UTC (permalink / raw) In article <37CFFA58.FFC67480@res.raytheon.com>, Andy Askey <askeya@res.raytheon.com> wrote: > Hello, > > I have several Ada legacy packages that contain multiple types. I > prefer that each type is in its own package/file for my Ada95 > development effort. Does anyone have (or know of) a script or other > tool that will turn a package with multiple types into multiple packages > with one type? Actually this is FAR more than a simple script can do, and indeed is not generally possible. Certainly if you have completely unrelated types in a single package with completely separate primitive operations, then the package should be split, but this is not the normal case. THe normal case is that you have multiple types in a single package is that they are related, and for example, you have operations that are primitive in more than one type. Asking how to break such packages into separate pieces so that there is only one type per package is like asking how to steer a car with the special proviso that you are not allowed to touch the steering wheel. The ability in Ada to have multiple types per package is one of the powerful features of the language, and it is quite difficult to do without if the program you are working with takes advantage of this feature. Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Package reformatting tool availability 1999-09-03 0:00 Package reformatting tool availability Andy Askey 1999-09-03 0:00 ` Robert Dewar 1999-09-03 0:00 ` Robert Dewar @ 1999-09-06 0:00 ` Pierre Dissaux 2 siblings, 0 replies; 9+ messages in thread From: Pierre Dissaux @ 1999-09-06 0:00 UTC (permalink / raw) Andy Askey wrote: > > Hello, > > I have several Ada legacy packages that contain multiple types. I > prefer that each type is in its own package/file for my Ada95 > development effort. Does anyone have (or know of) a script or other > tool that will turn a package with multiple types into multiple packages > with one type? > > Thanx. You could use Ada2HOOD reverse engineering utility in order to re-design your application. You will get a non-terminal HOOD module that is the image of your current composite package. It will be then possible to create lower level modules and dispatch types and related subprograms into each of them. This second step is not automatic, but can be performed in a graphic editor, if you can use a HOOD tool. Ada code may be re-generated with the new packages organization. Benefits of this approach is that you can work at design level, and justify creation of each "class" by proper documentation. HOOD (Hierarchical Object Oriented Design Method) was defined to fit software design process requirements for European Space Agency projects. It now also used for avionics, transport, and similar applications. HOOD4 (the last version of the method) is very close to Ada95. Ada2HOOD is freeware developed by TNI to help reengineering Ada software with a HOOD approach. Current version suffers from some limitations but it may be extended easily. It produces HOOD Standard Interchange Format (SIF) files from Ada packages. These SIF files may be loaded into any HOOD tool (and of course into STOOD, developed by TNI, but this one is not a freeware). To know more about HOOD/Ada design approach: - participate to the 3rd "Workshop on Methods and Tools for Ada95" (next week) http://workshopada.enst-bretagne.fr - visit our web site: http://www.tni.fr/ Pierre Dissaux TNI ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~1999-09-14 0:00 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1999-09-03 0:00 Package reformatting tool availability Andy Askey 1999-09-03 0:00 ` Robert Dewar 1999-09-07 0:00 ` Andy Askey 1999-09-08 0:00 ` Robert Dewar 1999-09-11 0:00 ` Richard D Riehle 1999-09-13 0:00 ` Robert Dewar 1999-09-14 0:00 ` Mark Lundquist 1999-09-03 0:00 ` Robert Dewar 1999-09-06 0:00 ` Pierre Dissaux
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox