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!mx02.eternal-september.org!feeder.eternal-september.org!gegeweb.org!news.ecp.fr!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Overriding puzzle Date: Sun, 3 Jan 2016 01:18:16 -0600 Organization: JSA Research & Innovation Message-ID: References: <5be84c5a-9614-4ee2-ae85-beb962171a05@googlegroups.com> <192c4493-9c53-4e23-b9bd-e4c543738dbc@googlegroups.com> <26e20ae9-ad86-4c88-9c67-f1a4a9b33f23@googlegroups.com> <677d0956-63d3-4de8-a6e5-b79c52a1dc12@googlegroups.com> NNTP-Posting-Host: rrsoftware.com X-Trace: loke.gir.dk 1451805497 7523 24.196.82.226 (3 Jan 2016 07:18:17 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Sun, 3 Jan 2016 07:18:17 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news.eternal-september.org comp.lang.ada:28989 Date: 2016-01-03T01:18:16-06:00 List-Id: "Niklas Holsti" wrote in message news:dek6taF5o9dU1@mid.individual.net... > On 15-12-31 01:10 , Randy Brukardt wrote: ... >> The model of Ada is that within a routine (including inherited routines) >> the >> object acts as if it had the named type. This makes it much easier to >> reason >> about the routine, as the behavior of all of the routines called is >> known. >> >> When you redispatch, you no longer can reason in any useful way about the >> behavior of the call -- essentially you are depending on "magic" (and the >> competency of others) to get the right answer. In limited circumstances >> (like the OP), it works well, but for general programming, look out! > > The same (IMO a bit paranoid) argument would logically apply to all > dispatching calls, including dispatching calls from class-wide > subprograms. It does. The problem is that Ada contracts aren't strong enough to describe LSP, so clueless (or hasty) programmers can easily write code that violates it. But let me back up a bit. Overloading has a similar problem, but that doesn't necessarily mean one has to avoid overloading. Nor do you have to avoid dispatching -- it just needs to be used judiciously. In the specific case of a class-wide subprogram (really a subprogram with class-wide parameters), the problem is more obvious (and less dangerous). You obviously can't reason about a call based on a specific type, so no one will try to do that. > The conclusion would be that one cannot reason in any useful way about any > dispatching call. I don't agree with that conclusion. Well, you could reason about a call based on LSP, but nothing in Ada forces the bodies to follow LSP, so in that case you're just hoping that everyone did the right thing. (And since people can extend in the future, you are hoping that someone years from now does the right thing -- good luck with that.) [Pre'Class helps a bit, but of course there is a lot that can't be described that way.] It's obviously harsh to say that you can't reason about a call, it's more that you are making a lot of assumptions in that case that don't necessarily hold. So you're on thinner ice that you typically realize. Randy.