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!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Preventing private procedure visibility being made public through extension Date: Sun, 21 May 2017 23:07:12 +0200 Organization: Aioe.org NNTP Server Message-ID: References: <4a47e4cd-829c-4451-abf1-82cf60b67706@googlegroups.com> <9cdf04e6-123e-4bd9-b466-77aad00d61bb@googlegroups.com> NNTP-Posting-Host: BYuA7L7MRjuLLjcoGHOBxw.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 X-Notice: Filtered by postfilter v. 0.8.2 Content-Language: en-US Xref: news.eternal-september.org comp.lang.ada:46842 Date: 2017-05-21T23:07:12+02:00 List-Id: On 2017-05-21 22:06, Jere wrote: > On Sunday, May 21, 2017 at 4:44:27 AM UTC-4, Dmitry A. Kazakov wrote: >> On 2017-05-21 00:51, Jere wrote: >>> On Saturday, May 20, 2017 at 4:32:07 PM UTC-4, Dmitry A. Kazakov wrote: >>>> On 2017-05-20 19:33, Jere wrote: >>> I do know that C++ supports hiding of functions by making them private >>> in the extending class. >> >> No. That is not possible in C++ either. A public method cannot be made >> private. >> >> In general from the OO point of view, a method cannot be removed because >> it is a property of the class and not of an individual type. It is the >> contract of the class to have a method Foo. All instances of the class >> must have this method. If they don't they are not instances of. Period. >> >> [To support method disallowing the language must support ad-hoc >> superclasses, so that one could split an original class into parts to >> chip the undesired operation away from one part and put the new type in >> that part instead of the whole original class.] >> > The language supports making them private in the context of the > extending classes. Take for example: > > class Base{ > public: > class Base_Param{}; > > void Something(Base_Param Obj){} Something is not a method here. If you make it a method [= Ada's primitive operation]: virtual void Something (Base_Param Obj); then your code will stop compiling. In Ada a non-primitive operation could be disallowed by declaring it abstract, just the same. An Ada example corresponding to yours is this: package Base is type Base_Type is null record; procedure Something (X : in out Base_Type); end Base; package Derived is type Derived_Type is new Base_Type; procedure Something (X : in out Derived_Type) is abstract; end Derived; X : Base_Type; Y : Derived_Type; begin Something (X); Something (Y); -- This won't compile > You're right, they are not proper constructors. I haven't found > anything in Ada yet that gives me that. At best they are > initializers. > >>> I really don't like doing this. I don't like using >>> access types for one. It's also doesn't feel like >>> a very clean way because you have to do something >>> out of the ordinary just to use the class like it was >>> meant to be. >> >> Aggregation + delegation is a decent thing. >> >> If you used anonymous access you would reduce dangers of pointers to zero. >> > Definitely. I am also worried about someone copying the access > value and holding onto it past the lifetime of the object. Anonymous access types are difficult to copy. Accessibility rules were made to prevent any unsafe copying. So you will have to break them by doing X.all'Unchecked_Access. > Temp : Base := Derived.Get_Base; -- didn't really want to allow This is illegal. It must be either Copy : Base := Derived.Get_Base.all; or Reference : Base renames Derived.Get_Base.all; Both are safe, yet have a very different semantics. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de