Re: Q: common types?!

[gamache@rapnet.sanders.lockheed.com]

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;        
--------------------------------------------------------------------