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!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Ada Distilled by Richard Riehle Date: Tue, 7 Aug 2018 00:01:14 +0200 Organization: Aioe.org NNTP Server Message-ID: References: <72ccb7fa-a9cb-42e6-8c29-3c06da281a45@googlegroups.com> <2212eb54-cb4a-446f-9cdf-287ef220e2c2@googlegroups.com> <1b5a58b2-65b7-4df8-80b5-03e208d249e1@googlegroups.com> <99a9127d-1024-4690-aa1d-8b3026a0f57d@googlegroups.com> <258b9e90-07e7-477c-99ba-204e328aea11@googlegroups.com> NNTP-Posting-Host: IzvqdhUtDGKIMCldyDtZ+w.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 X-Notice: Filtered by postfilter v. 0.8.3 Content-Language: en-US Xref: reader02.eternal-september.org comp.lang.ada:54071 Date: 2018-08-07T00:01:14+02:00 List-Id: On 2018-08-06 21:33, Vincent wrote: > Le samedi 28 juillet 2018 17:41:53 UTC+2, Dmitry A. Kazakov a écrit : > >> Ada 95 never had methods nested in type declaration. (Ada 83 did this >> error for protected objects and tasks, but the lesson was learned) > > What is the problem with methods nested in type declaration ? That no type has operations that only involve that type. Nested declarations prevent most of the types to have classes. In a sane language design all types must have classes. > It seems to me that with the Ada95 OO style, we have awful "freezing rules", and less visibility of which operation is dispatching and which is not. How are they awful? Clearly an incomplete type cannot be fully used. So there must be a freezing point where the type becomes usable. This has nothing to do with style, of which there is no choice. The only possible style is the Ada's one. All C++ proposals for MD switch to Ada style at once. Operations simply do not belong to a single type, there is no way they can be nested in a single type declaration. Considering dispatching, all operations should always be dispatching. Even a class-wide operation is dispatching on the class class etc. >> Yes, Ada's OO model is the only correct one, IMO. >> The concept of operations nested class type declaration is evident garbage in the light of MD. > > But that's a paradox since as you mentioned, this Ada model is not able to deal with MD ! On the contrary, nested declaration of operations automatically preclude MD. Where to place Print (Surface, Text)? In Ada model this problem does not exist: type Surface is ...; type Text is ...; procedure Print (X : in out Surface; Y : Text); Problems with MD lie elsewhere. > In both cases (in Ada and in languages that nest methods in types) one needs to deal with multiple dispatch "at hand" by an ad hoc procedure that uses class wide arguments and test them. That is not MD and it cannot handle MD except for few very special cases. In other cases it violates basic implementation requirements like compile time guaranty that all combinations of types are covered and that no faulty implementations are inherited. > For the obvious reason that there is no evident ordering of a pair of elements, event if each element is ordered. MD dispatching table is a multidimensional array. There is no ordering and therefore it is impossible to inherit all MD bodies. But some bodies can and must be inherited. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de