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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no 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!news4.google.com!proxad.net!feeder1-2.proxad.net!usenet-fr.net!club-internet.fr!feedme-small.clubint.net!news.teledata-fn.de!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Access types as parameters Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH 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> Date: Sun, 16 Aug 2009 10:32:45 +0200 Message-ID: NNTP-Posting-Date: 16 Aug 2009 10:32:42 CEST NNTP-Posting-Host: a7b3837d.newsspool2.arcor-online.net X-Trace: DXC==3gkF=JC6nYE47KDAk81NWA9EHlD;3YcR4Fo<]lROoRQ^YC2XCjHcbYhZ>f@UZj8b\DNcfSJ;bb[UIRnRBaCd 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. 2. procedure Foo (X1 : T; X2 : T'Class); called as Foo (X, X); Neither really represent a good design pattern. >> If you are in the operation inherited by S from T and you don't want it to >> be T there, then why do have you inherited and not overridden it in S? >> Something must be wrong in it. > > Not at all, it works perfectly for S. If I had overridden it for S, it > would have exactly the same text as for T (except of course for the > change in type name from T to S). That is a type error in Ada: you cannot call an operation of T on S, without a type conversion. Once you converted S to T, it is no more S. It is an ugly hack that allows you to restore S by casting it to T'Class. It is also a burden for the implementation. > If the operation did *not* use redispatching, it would *not* work for T > as well as for S, and I would have to override it for S. Yes, this is why S is not substitutable in the operations of T, you shall override it. The semantic problem is that you want to inherit "text", while substituting type annotations. This is not the model of inheritance. The proper models for this are class-wide operations and generic bodies. >> Are you saying that the reader must be constantly aware that the type of >> the actual parameter could be not the type the procedure deals with? > > Yes, of course. Because of inheritance. Shudder again. >> For example x*n defined as x+...+x, n times. you want to have a >> standard version of *, but in some cases to have an ability to >> implement it specifically. > > I think that is quite similar to the Divide/Conquer example. > >> I am using a sort of this: >> >> procedure Add (X : in out Item; Y : Item); >> procedure Mul (X : in out Item'Class; N : Positive); >> private >> function Has_Accelerated_Mul (X : Item) return Boolean; >> procedure Accelerated_Mul (X : in out Item; N : Positive); >> >> procedure Mul (X : in out Item'Class; N : Positive) is >> begin >> if Has_Accelerated_Mul (X) then >> Accelerated_Mult (X, N); > > Shudder (my turn :-). This is a kind of manually implemented overriding, > where Accelerated_Mul sometimes "overrides" Mul. I much prefer to use > the language-defined overriding of primitive operations, so I would make > Mul primitive on Item, instead of class-wide, and override it with an > accelerated version for those Item'Class types that allow it. This is > probably faster, too :-) There is no mechanism for it. 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. Considering this semantics, there is no necessity to sink the type tag down to T only to later raise it back to S. It should dispatch to S, not to T. So re-dispatch is still a hack that indicates a language problem here. I am using another hack in comparable situations: the Rosen trick. At least it makes explicit that each object "knows" itself. > One problem in your design is that someone can now mistakenly call > Accelerated_Mul (X) even if Has_Accelerated_Mul (X) is False. Accelerated_Mul is private. But you could merge it with Has_Accelerated_Mul. > Moreover, > Has_Accelerated_Mul seems to depend on the particular object (X), not > just on the type (Item). Or was this your intention? We cannot dispatch on bare tags in Ada, so I am forced to use object where the type tag would suffice. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de