Re: Extending a third party tagged type while adding finalization

[AdaMagica <christ-usch.grein@t-online.de>]

Aha, now I see what you are talking about. That's what I meant with cryptic message. You too often just expect mind reading (especially difficult with illegal code snippets).

Am Montag, 4. Dezember 2017 14:55:23 UTC+1 schrieb Dmitry A. Kazakov:
> On 04/12/2017 14:19, AdaMagica wrote:
> 
> > There is no Initialize defined for derived S. This is defined then implicitly as:
> > 
> >    procedure Initialize (X: in out S) is
> >    begin
> >      Initialize (T (X));
> >    end Initialize;
> > 
> > This is the calling sequence:
> > Init S
> > Init T
> > Foo  S
> 
> Which is a wrong sequence per Ada design. Actually it is just
> 
>     Initialize of S
> 
> This wrong sequence is fixed in practice by applying the pattern:
> 
>     procedure Initialize (X : in out Derived) is
>     begin
>        Parent (X).Initialize; -- Ensure parent's initialization
>        <do user initialization of Derived>
>     end Initialize;
> 
> Using the pattern you get a semantically correct sequence:
> 
>        -- enter Initialize of S
>        --   enter Initialize of T
>     <do user initialization of T>
>        --   leave Initialize of T
>     <do user initialization of S>
>        -- leave Initialize of S

That's the well-known Ada pattern you find in any text book. So what's your point?

> But with Foo it becomes wrong again:
> 
>     <do user initialization of T> + call Foo of S
>     <do user initialization of S>

Yes, because you specifically request a redispatch via the classwide pointer. You can correct this with

  procedure Initialize (X: in out T) is
  begin
    T (X.Self.all).Foo; -- no more Boom!
  end Initialize;

There were some discussions in CLA about not to use dispatch in Initialize et alii.

> Which is catastrophic and there is *no* way to make it right in presence 
> of multiple derived types. You cannot announce a call to a deferred 
> implementation during initialization of a specific type T. That may 
> happen only after initializations of all derived specific types are 
> complete.
> 
> Semantically it means that it must be called in the initialization of 
> T'Class. The proper sequence must be:
> 
>     <do user initialization of T>
>     <do user initialization of S>
>     <do user initialization of S'Class>
>     <do user initialization of T'Class> + call Foo of S

What do you mean by init of S'Class? There are no components of an S'Class. Sorry, I don't understand.