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=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD,
	FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4
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.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Mart van de Wege <mvdwege@gmail.com>
Newsgroups: comp.lang.ada
Subject: Re: Can't access record attribute in derived type
Date: Wed, 08 Mar 2017 22:12:07 +0100
Message-ID: <8660jj4gns.fsf@gaheris.avalon.lan>
References: <86mvcv4zyu.fsf@gaheris.avalon.lan>
	<o9pob6$ogc$1@franka.jacob-sparre.dk>
Mime-Version: 1.0
Content-Type: text/plain
X-Trace: individual.net YBaYvAjOOyTuDUYQPoqzGw9a8LUDxLuNC4Rcovjq0fhk+M9jxw
X-Orig-Path: gaheris.avalon.lan!not-for-mail
Cancel-Lock: sha1:BjiUP2gB5LQvoFOl255FS8K+AlU=
 sha1:T2Z/yRdPjD/VSB0QwjhraMIBGG4=
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)
Xref: news.eternal-september.org comp.lang.ada:33500
Date: 2017-03-08T22:12:07+01:00
List-Id: <comp.lang.ada>

"Randy Brukardt" <randy@rrsoftware.com> writes:

> I suspect we'll need to see a more complete example to definitively say what 
> the problem is.
>
The full code lives at https://github.com/mvdwege/pendragon

Note that some stuff is in incomplete branches, and I still have some
locally committed changes that are not in the github repo. The code that
was throwing errors among them.

> But if I had to guess, I'd suggest that you've run afoul of the "sibling 
> inheritance problem". The rule for visibility for child components is that 
> *all* of components of the *all* of the ancestors have to be visible at the 
> point of declaration of the child type. If even one of the ancestors is not 
> visible (as happens when deriving from a type defined in a sibling child 
> package), then the components aren't visible, either.
>
It appears that that is it. While Knights is a descendant of Person, the
Knights package is indeed a sibling of Persons, not a child.

I failed to let my package design keep up with the actual design of the
objects.

The problem went away when I moved the Knights definition into the
Persons package. Now I know why.

(In fact, my original design had a wild growth of child packages which I
was in the process of pruning back as being excessively complex. Which
probably caused my confusion above).

> Note that in such a case, if you have visiblity on some but not all of the 
> ancestors, you can type convert the object to make them visible. In your 
> example above:
>
>      return Creature(K).Parents.First_Element;

Yes, using conversions in my unit tests suppressed other errors I
couldn't get, and now I understand why those conversions were
necessary.

Mart

-- 
"We will need a longer wall when the revolution comes."
    --- AJS, quoting an uncertain source.