Re: Package reformatting tool availability

[Richard D Riehle <laoXhai@ix.netcom.com>]

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