Re: Inheritance versus Generics

[mfb@mbunix.mitre.org (Michael F Brenner)]

    Nick said > Fill me in on arrays of packages

Arrays of packages are what is missing in Ada-95 for packages to
act as objects. For example, in any generic instantiation which 
creates an ADO (abstract data object), you can use object oriented
notation to access the methods (package.method is identical to
object.method in this case. ) However, in the case of an ADT (abstract
data type), the package permits you to create a type (class) from 
which objects are then created. In this case package.method is not
equal to object.method; instead, you need to say package.method (object).
This partial inversion of the notation (object.method in ADOs versus
package.method for ADTs) results in many anomalies, such as most
existing generic code being ADOs, to make the objects LOOK like objects.
BTW, this method of grouping methods with the object not only preceeds
the great object-oriented languages such as smalltalk, Ada-95, and Java,
but also predates computer science. For example, category theory, 
abstract algebra, and discrete mathematics have all grouped the methods
with the objects, rather than using a structured programming approach
with a top-down design. Mathematicians have followed the best of the
object-oriented philosophy (design bottom up, relating the methods to
the objecs) but describe that design top down in a logical manner.

Making arrays of objects AS Packages would make packages into what is
called First Class Objects. This is not politically feasible given the
beliefs of the people who get to vote on this. However, making the
packages second class objects, that is permitting passing of packages
(non-generic) to packages adds no new problems; it only suffers from
the same things that any other form of multiple inheritance suffers
from. For example, if we have a double linked list package and 
a scheduling package and a 3d transformation package, there are
severe limitations to our ability to make linked lists of scheduled
transformation. We basically have to create each level of intermediate
object MANUALLY, inducing the comcomitant bugs, and imbuing the source
code with lines of code which packages as  second class objects 
would obviate. When you have existing packages and you know how 
you would like to parameterize them, it would be nice if Ada-2005
would permit you to do it. The type of problem we are trying to
solve in this discussion is the classical case of multiple
back ends for a single visible part. With external file systems
and configuration management tools, we can have multiple back ends.
However, within the Ada language, we can only do this if we have
a single level of inheritance (or if we manually create the
intermediate record types which, as said above, is error-prone). 
If packages were second class objects (passable to packages), then
we could re-instantiate new back ends for packates within the
language. While not as cool as arrays of packages, it would solve
the outstanding issue of programming for multiple backends within
the Ada-2005 language. It would NOT require the creation of packages
as TYPES, but rather would re-use the concept of abstract packages,
and merely relieve the restriction that packages as  parameters must
be generic. There are problems, yes, and those problems are worth
solving, yes. 
.