Re: Ada 90 inheritance request?

[eachus@spectre.mitre.org (Robert I. Eachus)]

In article <JGOODSEN.94Dec14144949@treasure.radsoft.com> jgoodsen@treasure.radsoft.com (John Goodsen) writes:

  > Of course, I don't really expect the ivory tower league to
  > undertake such a revealing comparison.  It makes too much sense
  > and would expose the err in the MI reasoning process.  Keeping
  > your balance on the soapbox seems to take priority over putting
  > Ada into the mainstream communities.

   Never being afraid to jump into the fray, I'll respond to John by
taking his MI example and asking why the obvious Ada 95 version is not
acceptable: 

    type Needs_Finalization is new Controlled with...;
    -- overriding of Initialize/Adjust/Finalize
    procedure Initialize (Obj : in out Needs_Finalization);
    procedure Adjust     (Obj : in out Needs_Finalization);
    procedure Finalize   (Obj : in out Needs_Finalization);

    type Ctrl_T is new T with record
      NF:  Needs_Finalization;
    end record;

    Now I can think of cases where this won't work, but they are
precisely the cases where the "true" MI version won't work either.
No, I take that back.  There are cases where true MI will fail, and
the Ada 95 version will sail through.  For example, if someone
modifies T so that it inherits directly from Controlled...

    In general where Ada 95 says "this is unsafe, so we will not allow
it," most MI languages say "this is really neat, and if you are VERY
careful, it will work, but never on large projects, because it doesn't
scale well."

     I've been there, I've done that, I've seen the maintenance
nightmares that can occur when more than one programmer depends on
unsafe MI on the same project.

     There is a lot of reasonable, and safe, MI out there.  But if you
check, it is all easily (and cleanly) translatable to Ada 95.  In this
case, I think it was Tucker who gave exactly the right answer--if
Ctrl_T needs to modify parts of T as part of assignment or
finalization, you really need to think long and hard about whether or
not other descendants of T will need to do the same thing.  If so, the
right choice is to make T a (direct or indirect) child of Controlled.
If not then you are almost certainly breaking the class model for T.
(Making Ctrl_T the root of it's own class, or the part of a class
rooted at Controlled, and having it add the "T" abstraction as a
component or mix-in is easy, if a solution without the "is a" property
is correct.)

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...