From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM
	autolearn=unavailable autolearn_force=no version=3.4.4
X-Received: by 10.99.109.74 with SMTP id i71mr1170364pgc.20.1498509331850;
        Mon, 26 Jun 2017 13:35:31 -0700 (PDT)
X-Received: by 10.157.3.34 with SMTP id 31mr37562otv.14.1498509331762; Mon, 26
 Jun 2017 13:35:31 -0700 (PDT)
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!news.glorb.com!185no1513324itv.0!news-out.google.com!k7ni534itk.0!nntp.google.com!x12no40033itb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.lang.ada
Date: Mon, 26 Jun 2017 13:35:31 -0700 (PDT)
In-Reply-To: <oipj61$pdq$1@franka.jacob-sparre.dk>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com;
 posting-host=213.108.152.51;
 posting-account=bMuEOQoAAACUUr_ghL3RBIi5neBZ5w_S
NNTP-Posting-Host: 213.108.152.51
References: <1ac5a44b-4423-443a-a7bb-2864d9abe78f@googlegroups.com>
 <b3cdaa6d-6be7-48f4-9df8-f9557d0bf9b6@googlegroups.com>
 <1498048151.20885.28.camel@obry.net>
 <96174ea5-852d-44e9-8535-7c1eb24d5326@googlegroups.com>
 <oie5u1$ktk$1@gioia.aioe.org>
 <8d3aff06-82df-485f-89e5-a50c326aab05@googlegroups.com>
 <66aa262e-2ac9-4016-b32d-e9fee14779e1@googlegroups.com>
 <88e2f18a-0786-4303-a5b8-fe82e8c81dcb@googlegroups.com>
 <bb2dce33-54bd-426c-9029-f965fa007e3b@googlegroups.com>
 <oipj61$pdq$1@franka.jacob-sparre.dk>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <71c4fdcd-4213-4b84-b852-c8674cfaf717@googlegroups.com>
Subject: Re: Ada Annoyances
From: Maciej Sobczak <see.my.homepage@gmail.com>
Injection-Date: Mon, 26 Jun 2017 20:35:31 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Xref: news.eternal-september.org comp.lang.ada:47132
Date: 2017-06-26T13:35:31-07:00
List-Id: <comp.lang.ada>

> C++ needs this model

In other words, what it offers is complete. Sounds fair.

> In Ada, where redispatching requires explicit work, the vast=20
> majority of constructors will never make a dispatching call so there is v=
ery=20
> little risk.

The vast majority? Where does this statistics come from?
I expect programmers to delegate initialization of the base parts to the in=
itialization procedure that was already written for the base part, like her=
e:

      procedure Initialize (Obj : in out Derived) is
      begin
         -- initialize Base part:
         Initialize (Base (Obj));
        =20
         -- initialize Derived part:
         -- ...
      end Initialize;

I'm not sure whether this is majority or minority, but the idiom seems to b=
e intuitive. The problem is - even though the view conversion is explicit h=
ere, the dispatching call in the Base version of Initialize is not and it i=
s there, where the potentially unsafe action can occur. These two places ca=
n be in separate files, written by different programmers. If you decouple e=
xplicit from unsafe, this is no longer in the Ada spirit.

The complete example (analogous to the C++ example I have written in the ot=
her post) is:

with Ada.Text_IO;
with Ada.Finalization;

procedure Test is
  =20
   package P is
      type Base is new Ada.Finalization.Limited_Controlled with null record=
;
     =20
      procedure Initialize (Obj : in out Base);
      procedure VFoo (Obj : in Base);
     =20
      type Derived is new Base with null record;
     =20
      procedure Initialize (Obj : in out Derived);
      procedure VFoo (Obj : in Derived);
     =20
      procedure Use_Object (Obj : in Base'Class);
   end P;
  =20
   package body P is
      procedure Initialize (Obj : in out Base) is
      begin
         Ada.Text_IO.Put_Line ("   call from Base's Initialize");
         Use_Object (Obj);
      end Initialize;
     =20
      procedure VFoo (Obj : in Base) is
      begin
         Ada.Text_IO.Put_Line ("      Hello from Base");
      end VFoo;
     =20
      procedure Initialize (Obj : in out Derived) is
      begin
         -- initialize Base part:
         Initialize (Base (Obj));
        =20
         Ada.Text_IO.Put_Line ("   call from Derived's Initialize");
         Use_Object (Obj);
      end Initialize;
     =20
      procedure VFoo (Obj : in Derived) is
      begin
         Ada.Text_IO.Put_Line ("      Hello from Derived");
      end VFoo;
     =20
      procedure Use_Object (Obj : in Base'Class)  is
      begin
         VFoo (Obj);
      end Use_Object;
   end P;
  =20
begin
   Ada.Text_IO.Put_Line ("test with Base");
   declare
      B : P.Base;
   begin
      null;
   end;
  =20
   Ada.Text_IO.Put_Line ("test with Derived");
   declare
      D : P.Derived;
   begin
      null;
   end;
end Test;

When executed, we get:

test with Base
   call from Base's Initialize
      Hello from Base
test with Derived
   call from Base's Initialize
      Hello from Derived   <<<<<<< here are dragons!
   call from Derived's Initialize
      Hello from Derived


> In any case, this problem is irrelevant.

So guess how did I learn about it...

> The net takeaway is that a truly type-safe language maybe could be=20
> constructed,

Yes. C++ got that part right.

--=20
Maciej Sobczak * http://www.inspirel.com