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!feeder.news-service.com!eweka.nl!lightspeed.eweka.nl!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!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> Date: Thu, 13 Aug 2009 23:07:54 +0200 Message-ID: NNTP-Posting-Date: 13 Aug 2009 23:07:51 CEST NNTP-Posting-Host: 1892bd9e.newsspool2.arcor-online.net X-Trace: DXC=S2?>H9?W_`e9kIfcjg:0fdA9EHlD;3Ycb4Fo<]lROoRa^YC2XCjHcbihZ>f@UZj8blDNcfSJ;bb[eIRnRBaCd On Thu, 13 Aug 2009 23:13:39 +0300, Niklas Holsti wrote: > Dmitry A. Kazakov wrote: >> On Thu, 13 Aug 2009 11:34:20 +0300, Niklas Holsti wrote: >> >>> 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. >> >> Shudder... > > Also an interesting reaction. > >> I consider re-dispatch is an indication of a language / design problem, >> because it is a hidden type error. An argument goes as follows. Once you >> have dispatched to some type T, the corresponding controlling parameter is >> of this type. Let we converted it to a class. If now it dispatches again to >> T, then that was just wasting time, if it dispatches to S /= T then it is a >> type error. > > To me that is a very abstract and formalistic argument that is easily > weaker than the practical benefits (providing sensible but overridable > default behaviour while avoding code duplication) that make me use > redispatching. If some formal premises are not satisfied (a type consistency is one of them) then it is meaningless to talk about benefits. In an extreme case, you might have an erroneous program that occasionally yields a correct result. Would you see a practical benefit here? > What is more, a central benefit of inheritance is that an > object can be viewed as being of parent type T *and also* of derived > type S, depending on the context and your needs, so I don't accept that > redispatching "to a different type" implies a type error. An object of the type S is already substitutable for T in the primitive operations of T and the operations of T'Class. Why do you want to re-dispatch? Re-dispatch means that an object pulls a trail of its history of type conversions (view conversion is a case of) throughout all substitutions of the object. This is a sufficiently more complex programming model, which semantics is doubtful. Instead of plain type T you have "S as T", or "S from R seen as T", and so on. That eliminates the advantage of clean Ada model that distinguishes T and T'Class. Your initial example was about certain decomposition of operations into class-wide and primitive, so that a primitive operation would call to class-wide ones. My point that such cases should be attributed to poor design or maybe to a language problem. One argument I gave was type inconsistency. There are also practical arguments that dispatching calls are slower, that re-dispatch requires referential semantics, that there would be no chance to have classes of by-value types like Integer etc. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de