Re: Difference between inheritance and package use

[jls@netcom.COM (Jim Showalter)]

>   Although there have been a number of good answers covering inheritance 
>(notably, Jim Showalter's), I haven't seen one which addressed one very
>basic difference between a C++ object and an Ada package.  The object is a
>first-class programming construct, where the package is not.  The
>encapsulation provided by a package is not as powerful as that in an
>object.  You can create an array of objects or pass an object to a
>subprogram.  Packages are static where objects are dynamic.

You can semi-fake "pure" OO
(should I be calling this "classic" OO instead of "pure"?) in Ada if you use
generic packages as first-class objects, since each instantiation of
such a package does indeed create a separate object, with operations
callable via the "pure" <object>.<method> form. Such packages, typically
with internal state, are cute, but they don't get you all the way there:
they can't be passed as arguments or assigned or stored in arrays, and
they don't inherit.

For example:

generic
    type Item is private;
package Universal_Stack_Class is

    procedure Push (This_Item : in Item);
    function  Pop  return Item;

end Universal_Stack_Class;

package My_Stack is new Universal_Stack_Class (Item => Integer);

My_Stack.Push (7);
Top := My_Stack.Pop;

Note how similar the two above statements are to C++ calls.

Sometimes you have a case where you want to use the above technique without
having even one generic formal--you just need it to be generic to have
the ability to create more than one instance of the package. This is fine.

I do NOT advocate using the above technique. Not only is there the simple
matter of pragmatics--multiple instantiations can be quite costly if you
are using a non-code-sharing (e.g. typical) compiler, and dynamic instantiations
can be REALLY expensive--but there is also the simple fact that a type is
a better object anyway, since it CAN be assigned, etc (more precisely, an
object of some type).

>   From what I've read in the Ada 9X reports, it appears that there is no
>plan to enhance the power of packages.  Instead, inheritance will be added
>to types*.  Does anyone have more complete information than that?

True enough. If you read the Rationale, package types get you sort-of but
not quite really what you want from classes, plus which it would be quite
difficult to migrate a design using the old model to a design using the
new model. I don't have a problem with this decision--whether inheritance
is added to the language via the type model or the module model is not
all that important, so long as it is added. (I realize that the majority
of "pure"/"classic" OO languages use the module route instead of the
type model route, but there are issues with the module route that are
kind of ugly that the type approach does not suffer from--I can elaborate
elsewhere if anybody is interested.)

Despite the above, I would like to see package types added to the language
for OTHER reasons--there are cases where passing a package is the single
best approach to design, and it should be supported, just as it should be
possible to pass procedures and functions. There are some indications in
the draft documents that they plan to support passing procedures and functions
(via, yuck, pointers--is there a C mole in the committee?), and that they
plan to support passing packages as generic actuals. I'd like to see them
all supported, and in the fully general case via function, procedure, and
package types. This would eliminate a lot of assymmetries in the language
definition and a lot of gotchas, although some are not comfortable with
this burring of the distinction between program and data (I think it makes
the language a lot more flexible and dynamic, goals stated in the overview
of the draft documents).
-- 
*** LIMITLESS SOFTWARE, Inc: Jim Showalter, jls@netcom.com, (408) 243-0630 ****
*Proven solutions to software problems. Consulting and training on all aspects*
*of software development. Management/process/methodology. Architecture/design/*
*reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++.    *