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: Ada Annoyances Date: Wed, 28 Jun 2017 09:57:15 +0200 Organization: Aioe.org NNTP Server Message-ID: References: <1ac5a44b-4423-443a-a7bb-2864d9abe78f@googlegroups.com> <1498048151.20885.28.camel@obry.net> <96174ea5-852d-44e9-8535-7c1eb24d5326@googlegroups.com> <8d3aff06-82df-485f-89e5-a50c326aab05@googlegroups.com> <66aa262e-2ac9-4016-b32d-e9fee14779e1@googlegroups.com> <88e2f18a-0786-4303-a5b8-fe82e8c81dcb@googlegroups.com> <71c4fdcd-4213-4b84-b852-c8674cfaf717@googlegroups.com> NNTP-Posting-Host: vZYCW951TbFitc4GdEwQJg.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 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 Content-Language: en-US X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:47152 Date: 2017-06-28T09:57:15+02:00 List-Id: On 27/06/2017 22:41, Randy Brukardt wrote: > "Dmitry A. Kazakov" wrote in message > news:oit1at$2vo$1@gioia.aioe.org... >> On 26/06/2017 23:40, Randy Brukardt wrote: > ... >>> As I tried to say yesterday, Ada does have a flaw in that allows >>> dispatching >>> calls within contructors (and more generally, inside of any primitive >>> operations). That requires work of some sort, but it is possible, and it >>> shouldn't be. >> >> Hmm, but what are you going to do about Rosen's trick? All use-cases where >> it is used (to work around language problems, constructors included) must >> be eliminated first. Only then re-dispatch could (and must) be outlawed. > > Avoid it? I've never used it in actual code, because it never seemed to save > anything (and it forces using limited types, which I avoid as much as > possible). I've always used an allocated "real-data-part" in the cases where > the Rosen trick might have helped. There are cases where I need it (or a class-wide discriminant similar to it): 1. Multiple inheritance emulated by mix-in. There is nothing wrong in proper mix-in, but in this case both objects are in fact the same one initialized at the same point with all problems following from that. 2. Components of [pointers to] task or protected type, since I cannot meaningfully use them via inheritance. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de