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.98.209.1 with SMTP id z1mr8116669pfg.27.1495403147056; Sun, 21 May 2017 14:45:47 -0700 (PDT) X-Received: by 10.157.84.44 with SMTP id j44mr420926oth.16.1495403146909; Sun, 21 May 2017 14:45:46 -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!67no1233902itx.0!news-out.google.com!m134ni5176itb.0!nntp.google.com!67no1233891itx.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sun, 21 May 2017 14:45:46 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=173.71.201.205; posting-account=QF6XPQoAAABce2NyPxxDAaKdAkN6RgAf NNTP-Posting-Host: 173.71.201.205 References: User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <1944a768-c92a-4f69-80b9-e79be32d037b@googlegroups.com> Subject: Re: Preventing private procedure visibility being made public through extension From: Jere Injection-Date: Sun, 21 May 2017 21:45:46 +0000 Content-Type: text/plain; charset="UTF-8" Xref: news.eternal-september.org comp.lang.ada:46845 Date: 2017-05-21T14:45:46-07:00 List-Id: On Sunday, May 21, 2017 at 5:20:36 PM UTC-4, Dmitry A. Kazakov wrote: > On 2017-05-21 22:21, Jere wrote: > > > The actual use case has > > them in separate packages, but the problem is the same: > > No. Robert meant that when you declare a subprogram in a separate > package [more precisely after the type's freezing point] it will not > become a primitive operation. A non-primitive operation is simply not > inherited and if not visible, is gone. Being not inherited is a very > important point, it will be rejected for derived types even if visible. > Consider this: > > package Base is > type Base_Type is tagged null record; > end Base; > > package Base_Something is > procedure Something (X : in out Base_Type; Y : Integer) is null; > end Base_Something; > > package Derived is > type Derived_Type is new Base_Type with null record; > end Derived; > > package Derived_Something is > procedure Something (X : in out Derived_Type; Y : String) is null; > end Derived_Something; > > use Base, Derived, Base_Something, Derived_Something; > X : Base_Type; > Y : Derived_Type; > begin > Something (X, 1); -- OK > Something (Y, 2); -- Type error! > Something (Y, "2"); -- OK > > -- > Regards, > Dmitry A. Kazakov > http://www.dmitry-kazakov.de Yes, but in the current case, Base_Type is already defined in a library with the procedures in the same package as the type. However, this is a good point for when I make my own types.