Re: Inherited Methods and such

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

"Maciej Sobczak" <see.my.homepage@gmail.com> wrote in message
news:1190842629.099822.65770@g4g2000hsf.googlegroups.com...
> On 26 Wrz, 14:21, Robert A Duff <bobd...@shell01.TheWorld.com> wrote:
>
> > Is this something fundamentally broken about constructors,
> > or is just another case of uninitialized variables?
> > I mean, there are lots of other ways to create uninit vars
> > in Ada...
>
> Yes, but for most of them it is easy to analyze the code and spot the
> problem.
> Most of them can be even found by the compiler itself, without
> involving any human-driven code review.
>
> Here the problem is in the interaction between base and derived type.
> The important feature of OO is that implementations (bodies) for T and
> S might not be available for review at the same time. If you look at T
> in isolation, it's clean. If you look at S in isolation (and this is
> the only thing you can do if you have only the interface ot T without
> the implementation), it's clean as well.
> Somehow together they don't work.

No, the problem is quite obviously with T. (Re)-dispatching within
Initialize is a sure-fire way to have a disaster. (A recent discussion on
the ARG list showed this again with dispatching calls in an extended return
statement.) OTOH, any program with such code in it is wrong. It's
unfortunate that there isn't a way for the language to disallow such
dispatching (as Initialize is an ordinary subprogram, after all). The same
is true inside of extended return statements. I wouldn't go as far as Dmitry
and disallow all redispatching, but it surely should not happen until the
object is fully constructed. (I suspect the same is true while it is being
finalized, but whether there is a real problem is not as obvious.)

                                   Randy.