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=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news3.google.com!feeder.news-service.com!news-out1.kabelfoon.nl!newsfeed.kabelfoon.nl!bandi.nntp.kabelfoon.nl!news.banetele.no!uio.no!fi.sn.net!newsfeed1.tdcnet.fi!news.song.fi!not-for-mail Date: Sun, 16 Aug 2009 12:52:53 +0300 From: Niklas Holsti Organization: Tidorum Ltd User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090706) MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Access types as parameters References: <521c4843-d40f-4545-9e80-ca725e847090@h21g2000yqa.googlegroups.com> <8410fc60-9b8a-4f82-92fc-622a6bbe5931@i18g2000pro.googlegroups.com> <8880c3d0-a07f-4d4e-ac87-372014598576@d15g2000prc.googlegroups.com> <4a83d018$0$26303$4f793bc4@news.tdc.fi> <4a847400$0$26304$4f793bc4@news.tdc.fi> <4a852df2$0$26317$4f793bc4@news.tdc.fi> <1jrxo2acn8evc.x3wfcmp4etbo.dlg@40tude.net> <4a858af5$0$24774$4f793bc4@news.tdc.fi> <4a870a5b$0$26302$4f793bc4@news.tdc.fi> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <4a87d705$0$24771$4f793bc4@news.tdc.fi> NNTP-Posting-Host: 81.17.205.61 X-Trace: 1250416391 news.tdc.fi 24771 81.17.205.61:36036 X-Complaints-To: abuse@tdcnet.fi Xref: g2news2.google.com comp.lang.ada:7826 Date: 2009-08-16T12:52:53+03:00 List-Id: Dmitry A. Kazakov wrote: > On Sat, 15 Aug 2009 22:19:41 +0300, Niklas Holsti wrote: > >> Dmitry A. Kazakov wrote: >>> On Fri, 14 Aug 2009 19:03:52 +0300, Niklas Holsti wrote: >>> >>>> Of course not, only the point (within the class) of the implementation >>>> of the currently executing, (possibly) inherited operation (the caller) >>>> is determined. The actual type, as you well know, is any type in >>>> T'Class, although it is written "T" in the operation profile. >>> No, the actual type is T, just because the operation declaration tells so. >> This seems to be the origin of our disagreement. You want to view the >> object as of type T, although at run-time it may be a T-view of an >> object of a derived type S. This means that you cannot redispatch. But >> this does not entitle you to call redispatching "bad" in general. > > Ada does not allow other cases, I mean dispatching while preserving a > class-wide view on the object. What comes in mind: > > 1. procedure Foo (X : T'Class) is > begin > if X in S'Class then > Bar (X); -- Now "dispatch" again > elsif X in Q'Class then > Baz (X); -- "dispatch" again > > This is a form of re-dispatch since the tag of X is analyzed twice. I don't see how this relates to our subject. Yes, that code looks at the tag of X. Are you saying that any inspection of the tag of an object is "bad design", except for the case of "basic" dispatching? Although I sometimes do it, I don't much like to inspect tags, as in Foo above, because it couples the logic of a class-wide operation to the existence and properties of certain explicitly named sub-classes, which is fragile. But a redispatching call is not fragile in this way. > Re-dispatch is a hack. What do you do is > semantically not inheritance but overriding with an instance of a generic > body, or some class-wide body. I think this is the key issue. I'm sorry, I don't understand why it is "semantically not inheritance". If this is again the "type error" issue, I still don't agree with you. Your other arguments use terms and concepts that are too vague (for me) to be argued about, so I don't see how we can progress usefully. Thanks for the discussion. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .