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!nntp-feed.chiark.greenend.org.uk!ewrotcd!newsfeed.xs3.de!io.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Ada Annoyances Date: Mon, 26 Jun 2017 16:40:50 -0500 Organization: JSA Research & Innovation 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: rrsoftware.com X-Trace: franka.jacob-sparre.dk 1498513252 739 24.196.82.226 (26 Jun 2017 21:40:52 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Mon, 26 Jun 2017 21:40:52 +0000 (UTC) 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.6157 Xref: news.eternal-september.org comp.lang.ada:47134 Date: 2017-06-26T16:40:50-05:00 List-Id: "Maciej Sobczak" wrote in message news:71c4fdcd-4213-4b84-b852-c8674cfaf717@googlegroups.com... ... >> In Ada, where redispatching requires explicit work, the vast >> majority of constructors will never make a dispatching call so there is >> very >> little risk. >The vast majority? Where does this statistics come from? Common sense. Constructors shouldn't be doing anything complicated in the first place, so there's not much reason for delegation. Even if you do use it, dispatching calls are rare in good Ada code. Most of them come from factories or global data structures, which are irrelevant here (you're not using those things on the constructed object itself within a constructor). In any case, interfaces and other forms of OOP dispatching are greatly overrated; the cases where they can be profitably employed in real-world programs are quite rare. (There's much more value from type extension and implementation inheritance.) 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. It's too late to fix that in terms of the language, but it's easy enough to check with tools like AdaControl. >I expect programmers to delegate initialization of the base parts to the >initialization > procedure that was already written for the base part, like here: Surely. >I'm not sure whether this is majority or minority, but the idiom seems to >be intuitive. >The problem is - even though the view conversion is explicit here, the >dispatching >call in the Base version of Initialize is not and it is there, where the >potentially >unsafe action can occur. A dispatching call in *any* version of Initialize is a problem, is unnecessary, and should have been banned by the language. Don't do it, and you'll have no problem to worry about. (And that it true for every primitive - "method" in C++ terms.) ... > These two places can be in separate files, written by different > programmers. > If you decouple explicit from unsafe, this is no longer in the Ada spirit. Yes, of course if you call broken code, your code will end up broken too. Hard to see what could be done about that - it's always possible that the base class is written by an incompetent programmer. (Another reason that I personally don't think too much of OOP - I want control of everything I write -- if I'm going to make a fatal mistake, I at least want it to be something that I can improve next time.) >The complete example (analogous to the C++ example I have written in the >other post) is: I don't buy the usefulness (in real code) of a class-wide Use_Object. My experience has been such routines almost always end up needing to be primitive (and definitely true in this case). In any case, we both agree that you shouldn't be able to call Use_Object in this case, I suspect our reasons differ but the effect is the same. >> In any case, this problem is irrelevant. > >So guess how did I learn about it... You wrote some ill-advised Initialize routines? Re-dispatching is almost always evil, do it only after VERY careful consideration. (Note that we had to fix Pre'Class/Post'Class so they didn't unintentionally cause redispatching, as the effect was that a body might not have had the precondition it was expecting to have been evaluated). >> The net takeaway is that a truly type-safe language maybe could be >> constructed, > >Yes. C++ got that part right. You completely ignored my point about order of initialization, which destroys any type-safety up-front. I don't think C++ (or any other mainstream language) even tries to get that right... Randy.