Re: abstract sub programs overriding

["Randy Brukardt" <randy@rrsoftware.com>]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1079013337.572283@master.nyc.kbcfp.com...
> Robert I. Eachus wrote:
> > No, as I said, there are two common idioms, the first is to call the
> > parent Initialize AFTER doing any initialization work needed on the
> > fields that occur only in the child.
> >
> > procedure Initalize(Object: in out Child) is
> > begin
> >   Do_Something(Object);
> >   Initialize(Parent(Object));
> > end Initialize;
...

I have no idea what Robert is talking about here. The "common idiom" that I
use is:

procedure Initalize(Object: in out Child) is
begin
   Initialize(Parent(Object));
   Do_Something(Object);
end Initialize;

On the other issue, it's clear that a class-wide call in Initialize can be
forced to dispatch to a routine which can see uninitialized components. But
such a dispatch (which you always have to write explicitly) is a bug in
Initialize/Adjust/Finalize. You *never* want dispatching on the operative
object in the implementation of these routines, and doing such is a mistake.
It's true that Ada doesn't protect you from this mistake, but its one that
you have to work at pretty hard to make.

It's unfortunate that Ada doesn't have a sane way to call the parent
operation (using a type conversion to a specific type is ugly and
potentially a source of error if another type is inserted into the
hierarchy), because that is the most likely way to insert a dispatching call
by accident. DK, seems to want to outlaw redispatching altogether (which is
too fierce to me), but such a rule would eliminate any possibility of
accessing uninitialized components in these routines.

(Of course, in practice, default initialization of the components does most
of the work, so it's fairly rare that Initialize does anything important at
all. Which reduces the consequences of the [unlikely] error to very little
anyway.)

                     Randy.