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 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!gandalf.srv.welterde.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Full view of a private partial view cannot be a subtype Date: Mon, 18 Dec 2017 16:54:29 -0600 Organization: JSA Research & Innovation Message-ID: References: Injection-Date: Mon, 18 Dec 2017 22:54:30 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="20768"; mail-complaints-to="news@jacob-sparre.dk" X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 Xref: reader02.eternal-september.org comp.lang.ada:49526 Date: 2017-12-18T16:54:29-06:00 List-Id: "Stephen Leake" wrote in message news:ceef5c1e-b80b-42c7-9d11-12e52dc6c266@googlegroups.com... > On Saturday, December 2, 2017 at 8:14:50 PM UTC-6, Jere wrote: >> There are times where in another package I want to >> subtype Base.Instance and do renames of the operations in order >> to bring them all into scope (or whatever the correct term is): >> >> package New_Type1 is >> subtype Instance is Base.Instance; >> procedure Operation(Object : in out Instance); >> >> private >> >> procedure Operation(Object : in out Instance) renames >> Base.Operation; >> end New_Type1; > > Why subtype? why not a derived type? why do you need a new name with the > same operations? > >> (NOTE: is there a better way to do this?) > > Yes, use a derived type: > > type Instance is new Base.Instance; > > Since Base.Instance is not abstract, you don't need to do anything else; > all the operations are inherited. > > Optionally, you can override some operations to change what they do. > >> So I guess my question is two part: >> >> 1. Is there a way to make the full view of a private type >> a subtype when the partial view is not a subtype? Or am >> I forced to derive a new type? >> >> 2. If it isn't possible, are there any language reasons for >> why that must be so? Would making a full view of a type >> actually a subtype under the hood break something? > > subtypes just declare a new name with new constraints; derived types > declare a new type. So you'd be lying to the clients of the package; > that always causes problems. Right. The type model of Ada is that every named type is disjoint. For the perspective of a client, a private type is different than any other type that it could know about. OTOH, a subtype is the *same* type as some other type. So you would have view-dependent typing (depending on where you are in the program, it would differ as to whether whether the types are distinct or the same). We have a saying for such thing in the ARG: "that way lies madness!". The only other way to make it work would be to abandon strict privacy, and have the semantics of a private type depend on the completion. That would be totally contrary to the goals of Ada, so that's not a serious option, either. So this is not happening, it does not make semantic sense. Randy.