Re: Ada 90 inheritance request?

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

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

  > Maybe it's just me not seeing something here (which could be an indicator
  > of the usability issues involved with addressing MI in Ada95), but where 
  > is the polymorphic behavior in the MI lattice?  Wouldn't the above solution
  > require me to delegate methods to the NF member of Ctrl_T (by hand)?

  You lost me here. Initialize, Finalize, and Adjust have to be
defined on NF, but not on Ctrl_T.  All the operations on T
are derived for Ctrl_T, and appropriate dispatching occurs.  The ONLY
issue, as has been discussed is if you need finalization, etc. for
some part of the inherited T, or if you need access to the inherited
parts of T to do the initialization, etc.  But as I (and others) see
it, the major problem in that case is the broken abstraction, not the
unsafe approaches to implementing the operations.

 > This isn't clear to me.  Can you give an example (besides the overused
 > diamond inheritance pattern) ?  What do you mean by "unsafe MI" ?

    The easiest definition on a large project is any case where a new
subclass of one of the parents (or a change to one of the existing
subclasses) can break the MI inheriting class.  The usual break is
when a new subclass of class A has a method which conflicts with a
method inherited from class B, and you apply a class-wide operation of
the MI class to a member of that subclass (with casting as necessary).
You can get a dispatching call in some other method which now calls
the "wrong" method, and there is no point visible to a single
programmer where all this is visible.

    That's the major "doesn't scale" problem.  Ada 9X avoids it by
insisting that both of the methods involved must have a common
template inherited from a single parent.  If you have two mix-ins with
the "same" method, the visibility rules, not the dispatching rules
determine which gets called.  (Unless, as stated, they both explicitly
match a template in a superclass.  But in that case, we do have a
warning flag.)
  

--

					Robert I. Eachus

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