From: Simon Wright <simon@pushface.org>
Subject: Re: Type vs subtype about visibility of parent's private full definition
Date: Thu, 16 May 2013 16:29:13 +0100
Date: 2013-05-16T16:29:13+01:00 [thread overview]
Message-ID: <lyk3mzx7sm.fsf@pushface.org> (raw)
In-Reply-To: op.ww383ycoule2fv@cardamome
"Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr> writes:
> I already encountered something similar in the past, and it's back
> again. I can only solve it using a subtype instead of a type‑new where
> I initially want a type‑new, so I'm not happy with using subtype.
>
> The case: a child package don't see the full definition of a type from
> the private part of its parent package when it derives from that type
> as a type‑new.
>
> Below is an example, using a discriminant, which is not required to
> expose the visibility issue, but which is the reason why I'm not happy
> to not be able to derive a type‑new instead of a subtype: I can't
> force static‑check as I expected. If the discriminant was not part of
> the party, I won't bother. That's the reason why the example makes use
> of a discriminant and I see the case as an issue.
>
>
> Example:
>
>
> package Parents is
>
> pragma Pure;
>
> type Discriminant_Type is
> range 1 .. 5;
>
> type Instance_Type
> (Discriminant : Discriminant_Type) is
> private;
>
> private
>
> type Instance_Type
> (Discriminant : Discriminant_Type) is
> record
> Value : Integer;
> end record;
>
> end Parents;
>
> package Parents.Childs is
>
> pragma Pure;
>
> subtype Parent_Type is
> Parents.Instance_Type;
>
> type Instance_Type is
> new Parent_Type
> (Discriminant => 2);
There may or may not be a compiler bug triggered by this form, but I
don't understand why you say "I can only solve it using a subtype
instead of a type‑new where I initially want a type‑new, so I'm not
happy with using subtype" because if I write instead of Parent_Type and
Instance_Type above
type Instance_Type is
new Parents.Instance_Type
(Discriminant => 2);
or
subtype Instance_Type is
Parents.Instance_Type
(Discriminant => 2);
it compiles OK.
> function Value
> (Object : Instance_Type)
> return Integer;
>
> private
>
> function Value
> (Object : Instance_Type)
> return Integer
> is (Object.Value); -- << Error here
>
> end Parents.Childs;
>
>
> I did not check the RM, however I'm blocked if I do this, as GNAT has
> complaints with `is (Object.Value)`, and grumbles:
>
>
> no selector "Value" for private type derived from "Instance_Type"
>
>
> I can just work around it, defining `Parents.Childs.Instance_Type`
> this way:
>
>
> subtype Instance_Type is
> Parent_Type
> (Discriminant => 2);
>
>
> … instead of this way (as was in the above package definition):
>
>
> type Instance_Type is
> new Parent_Type
> (Discriminant => 2);
>
>
> I may be naive, I believe `Parents.Childs` private part should see the
> full definition of `Parents.Instance_Type` in both case, not only when
> deriving a subtype.
>
> What are your opinions about this issue?
next prev parent reply other threads:[~2013-05-16 15:29 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-15 8:13 Type vs subtype about visibility of parent's private full definition Yannick Duchêne (Hibou57)
2013-05-15 14:44 ` Adam Beneschan
2013-05-15 20:45 ` Yannick Duchêne (Hibou57)
2013-05-16 13:54 ` Marc C
2013-05-17 0:01 ` Randy Brukardt
2013-05-17 15:48 ` Adam Beneschan
2013-05-16 15:29 ` Simon Wright [this message]
2013-05-16 20:25 ` Yannick Duchêne (Hibou57)
2013-05-16 20:28 ` Yannick Duchêne (Hibou57)
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox