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-Thread: a07f3367d7,7ff1de84a8945e80 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes 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!xindi.nntp.kabelfoon.nl!news.banetele.no!uio.no!fi.sn.net!newsfeed2.tdcnet.fi!news.song.fi!not-for-mail Date: Fri, 14 Aug 2009 13:22:38 +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> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <4a853afa$0$24763$4f793bc4@news.tdc.fi> NNTP-Posting-Host: 81.17.205.61 X-Trace: 1250245370 news.tdc.fi 24763 81.17.205.61:54206 X-Complaints-To: abuse@tdcnet.fi Xref: g2news2.google.com comp.lang.ada:7766 Date: 2009-08-14T13:22:38+03:00 List-Id: Randy Brukardt wrote: > "Niklas Holsti" wrote in message > news:4a83d018$0$26303$4f793bc4@news.tdc.fi... >> Randy Brukardt wrote: >> >>> You almost never want redispatching >> That's interesting as my experience is the opposite: Most of the calls >> between primitive methods in my code use redispatching. >> >> My tagged types tend to have a hierarchy of primitive operations, for >> example an Overall_Method that implements some functionality by a sequence >> of calls to a Detail_Method. Some derived types override Detail_Method, so >> the call from Overall_Method to Detail_Method must redispatch. Some other >> (or the same) derived types override Overall_Method, so it cannot be >> class-wide. > > It seems to me that one or the other of these routines ought to be > class-wide, the fact that neither can be is a design problem. But YMMV. Thanks for understanding that YMMV. Perhaps I can explain my context a bit more. Think of a class of problems that can be solved with a divide-and-conquer approach (this is not exactly my application, but it is similar). There are thus two operations: "Divide" a problem into cases, and "Conquer" a given case. There is a general, but rather slow, way to Divide any problem in the class, so the root type implements a Divide operation that applies this general procedure and then calls Conquer for each case that it generates. Some special kinds of problems (derived types and subclasses) have faster, specialized forms of Divide, so Divide is overridden for these types. Each kind of problem (derived type) has a specific Conquer method, and so each derived type overrides the Conquer operation (which is usually abstract in the root type, in fact, but that is incidental). > The primary reason that you don't (usually) want redispatch is that it is > hard to guarentee the semantics of a routine if it re-dispatches and thus > calls routines with unknown semantics. Agreed, but that argument applies as well to any kind of run-time dispatching, not just *re*-dispatching, and thus for example to dispatching calls from class-wide operations. If you have a class C with primitive operations Frobnicate and Dazzlify, which are expected to fulfil some application requirements, it is surely part of the programming task to ensure that each overriding Frobnicate or Dazzlify has the right semantics for its type, in whatever context it is called, whether using "basic" dispatching or redispatching. Assuming, of course, that the calls obey whatever preconditions are required for those operations. > For Ada predefined libraries, we went > so far as to create a rule that calls do *not* redispatch - A(3.1/3) > (You'll have to look in the draft RM to see that one, since it was > added in response to a question on Ada 2005: That question came from me, I think (15 Feb 2007). > see http://www.adaic.com/standards/1zrm/html/RM-A.html). To quote: > > "For a descendant of a language-defined tagged type, the implementation > shall ensure that each inherited language-defined subprogram behaves as > described in this International Standard. In particular, overriding a > language-defined subprogram shall not alter the effect of any inherited > language-defined subprogram." Nice to see that my question led to something, thanks. > In short, don't redispatch in language-defined routines. That was the solution I suggested in my question on Ada-Comment, as being the simplest solution. But it is not the only possible solution; another solution would have been to specify the redispatching that language-defined routines must or may do. As Tucker Taft commented, "redispatching must be seen as part of the *specification* of the primitive operation of a tagged type". Of course, in my own code I carefully specify which operations use redispatching :-) > Re-dispatching is really only safe semantically if you can guarentee that > the functionality of any overriding is a superset of that of the base > operation. But of course there is no way to guarentee that in Ada; Unfortunately, Ada does not guarantee that you write a correct program, period. (But I do find that she helps.) > Of course, sometimes the semantics aren't very firmly defined, and > redispatching works fine. I would say, rather, that redispatching works fine *if* the semantics of the primitive operations *are* firmly defined, with redispatching in mind. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .