Re: Inheritance versus Generics

["John G. Volan" <johnvolan@sprintmail.com>]

Michael F Brenner wrote:

> Arrays of packages are what is missing in Ada-95 for packages to
> act as objects.

I must admit that I find this whole discussion of packages as first- or
second- class objects somewhat confusing.  I don't quite see what they
buy you that isn't already supported by tagged record types and
generics.  Michael, it might be helpful if you could post a "code"
example that showed what you had in mind for the syntax and semantics of
these beasts. :-)  Then either someone could show you that what you want
can actually be done in Ada95, or else you could make it clear what is
missing.

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

Sigh ... is this just a religious issue over cosmetics?  Why so much
bitterness over superficial syntactic differences?   Isn't it plain that
there's a _semantic_ homomorphism between these two notations:

                 controlling parameter (target)
                 distinguished by type analysis
                 (doesn't necessarily have to be first)
                    |
                    |
    scope.method (target, parameters);  -- Ada95: scope = package  
         |                              -- "scope." can be omitted
         |                              --  after a "use"
   period as        
 scope delimiter      

               double-colon
               as scope operator
                |
                | 
    target.scope::method (parameters);  // C++: scope == class 
          |                             // "scope::" can be omitted
          |                             // anytime
        controlling parameter (target)
        distinguished by period syntax

Can you not see how parochial your interpretation of the period
character (.) is?  An analogy: In the United States, we write out
numbers thus: "123,456.789". In some countries in Europe, the same
number might be written thus: "123.456,789".  A telephone number in the
US is usually written like this: "(800) 555-1212".  The same number
might be written in Europe as: "800.555.1212".  Does anyone have a
problem with this?  _I_ sure don't.  I can figure out what is meant
either way.

> BTW, this method of grouping methods with the object not only preceeds
> the great object-oriented languages such as smalltalk, Ada-95, and Java,

What about Common Lisp? A very object-oriented language indeed, and yet
it manages to do this without changing the old Lisp syntax:

    (method target parameters)  ;; controlling parameter doesn't 
                                ;; necessarily have to be first

> but also predates computer science. For example, category theory,
> abstract algebra, and discrete mathematics have all grouped the methods
> with the objects, 

Mathematics groups methods with _objects_? Or does it group methods with
_types_? What do you mean by "grouping"?  An Ada95 package can declare a
type and its associated primitive subprograms together. In fact, that's
what defines those subprograms as "primitive" -- their co-location in
the same package spec with the type.  In what way does this fail to
achieve the "grouping" you seek?  Why do I suspect that it won't count
as "grouping" unless it is attended with the "politicially correct"
syntactic sugar?

> rather than using a structured programming approach
> with a top-down design. 

What does this have to do with Ada95?  Are you somehow insinuating that
Ada95 packages cannot support any notion other than top-down structured
design?  Surely you can't mean that, given the overwhelming evidence to
the contrary!

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

Sounds like sour grapes to me.  I do remember seeing something about
package types way back when during the Ada9X process.  I bet they were
discussed seriously and extensively.  But, as we all know, a different
solution was chosen instead.  It is my belief that the current solution
can be shown to be _semantically homomorphic_ to whatever it is that you
want, but it will take a concrete example to demonstrate that.

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

Interesting.  How would your package-passing concept create "multiple
inheritance"?  And why do you think multiple inheritance is what you
need to solve the kind of problem you describe, anyway?  MI is not the
only technique for flexibly composing abstractions.  Sounds like a case
of "hammer syndrome" to me (that's where every problem looks like a
nail).

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

Interesting.  It seems to me that something like this _can_ be achieved
with tagged types, combined with generics.  Let's see this example
fleshed out a bit, then we can talk.

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

Why can't this be achieved using an abstract tagged type with multiple
concrete derived types and classwide programming?

> 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).

Interesting.  Again, a fleshed out example might be instructive.

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

Well, maybe they've _already_ been solved...

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name => "John G. Volan",  Home_Email => "johnvolan@sprintmail.com",
   Slogan => "Ada95: The World's *FIRST* International-Standard OOPL",
   Disclaimer => "These opinions were never defined, so using them " & 
     "would be erroneous...or is that just nondeterministic now? :-) ");
------------------------------------------------------------------------