comp.lang.ada
 help / color / mirror / Atom feed
From: Robert A Duff <bobduff@shell01.TheWorld.com>
Subject: Re: Strange error message
Date: Mon, 02 Jun 2014 09:49:13 -0400
Date: 2014-06-02T09:49:13-04:00	[thread overview]
Message-ID: <wcc38fn5sme.fsf@shell01.TheWorld.com> (raw)
In-Reply-To: 17l7hex6vxkj4.wul0z12r7f85.dlg@40tude.net

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> The first objection is that the legality of inheriting Create in
>
>    type Base is tagged private;
>    function Create return Base;
>
>    type High is new Base with private;
>  
> depends on the private part of the package. This is not good.

Privacy breakage is not good, but there is no privacy breakage here.
Privacy breakage happens when the legality of clients depends on the
contents of the private part.  Here, the legality of the package itself
depends on the contents of the private part (which is always the case!).

Clients can only see the visible part as quoted above.
The private part could be:

    private
       type Base is tagged null record;
       type High is new Base with null record;

or:

    private
       type Base is tagged null record;

       type High is new Base with record
          H_Val : Natural;
       end record;
       overriding function Create return High is
         (Base'(Create) with H_Val => <>);

both of which are legal.  The visible part promises that there
will be a function Create returning High.  The first private part
above accomplishes that by using the one implicitly generated
by the compiler, which looks like this:

       function Create return High is (Base'(Create) with null record);

If you wrote it by hand (as you were required to do in Ada 95), you
would almost certainly write something equivalent.  What else could it
reasonably do?

The compiler can't automatically create Create in the second case,
because it doesn't know what value you want for H_Val.

> The second objection is, if the above is not good then
>
>    type High is new Base with null record;
>
> should make no difference.

Well, since your first objection is invalid, the premise of
your second objection is false.  ;-)

> ---------------
> Of course one could argue in favor of the rule that all primitive
> operations are in some sense overridden anyway. It is only the way the
> bodies are constructed (inherited vs. provided by the user), what makes
> difference. I.e. whether
>
>    overriding function Create return High;
>
> appears in the public part of the package or not, that is an implementation
> detail uninteresting to the clients. I would agree with that, but it is not
> how the language is designed presently.

Not sure what you mean.  You can put the above "overriding..." in the
visible part or the private part, or (in the null record case) leave it
out.  It makes no difference to clients.

> It is, as always, too late, but probably overriding (with new body) were to
> appear strictly in the package body.

Yes, that would make sense.  I suggested that during Ada 9X.  The
reasons not to do that have to do with making compilers easier to write.

In fact, private parts should not exist; that stuff belongs in the body.

>...Then the rule of null extension would
> be all OK to me.

Is it OK with you now, having read my comments above?

- Bob


  reply	other threads:[~2014-06-02 13:49 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-01 10:24 Strange error message Charly
2014-06-01 11:11 ` Dmitry A. Kazakov
2014-06-01 12:50   ` Charly
2014-06-01 13:54     ` Simon Wright
2014-06-01 21:18 ` Robert A Duff
2014-06-02  7:47   ` Dmitry A. Kazakov
2014-06-02 13:49     ` Robert A Duff [this message]
2014-06-02 14:55       ` Dmitry A. Kazakov
2014-06-02 17:24         ` Robert A Duff
2014-06-02 18:39       ` Shark8
2014-06-02 19:56   ` Randy Brukardt
  -- strict thread matches above, loose matches on Subject: below --
2002-11-13 10:36 strange " evangeli
2002-11-13 15:05 ` Stephen Leake
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox