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 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!news.cs.hut.fi!newsfeed2.funet.fi!newsfeeds.funet.fi!xlned.com!feeder5.xlned.com!newsfeed.xs4all.nl!newsfeed1.news.xs4all.nl!xs4all!news.stack.nl!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Your wish list for Ada 202X Date: Fri, 11 Apr 2014 22:43:19 +0200 Organization: cbb software GmbH Message-ID: References: <7f1c01c5-3563-4b94-9831-152dbbf2ecdc@googlegroups.com> <8bhozh836pyt$.1qctlysud0s2q$.dlg@40tude.net> <1cdsyxjzsfgzm.1synpaujysv21$.dlg@40tude.net> <1aa804jg9qq4o$.wdiq33yo621l.dlg@40tude.net> <1w6eh0aiksmdh$.1h16p7y0b8c6h.dlg@40tude.net> <17twpp4p8u7o$.1idvzaaio4f3t$.dlg@40tude.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: AuYlnUSfTZrfhAkRjyySpQ.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:19249 Date: 2014-04-11T22:43:19+02:00 List-Id: On Fri, 11 Apr 2014 21:04:58 +0200, Niklas Holsti wrote: > On 14-04-10 17:31 , Dmitry A. Kazakov wrote: >> On Wed, 9 Apr 2014 22:28:36 -0500, Randy Brukardt wrote: > > [snip] > >>> We don't want "type-specific" implementations of most things -- that's just >>> adding a maintenance headache where one isn't needed. >> >> It is need for >> >> 1. safety (because you statically know that certain specific operation may >> not fail, while class-wide operations can) >> >> 2. efficiency >> >> There is no maintenance overhead whatsoever. Here is the proof. Let you can >> provide a generic implementation (as you suggested), then this >> implementation can be safely inherited. > > If you change a class-wide operation to an inherited (i.e. primitive) > operation, you have to change its dispatching calls to redispatching > calls, if you want the same behaviour as for the class-wide operation. No. I meant that the behavior of class-wide operation was defined = there were no re-dispatch to operations that could be overridden to some unanticipated behavior. If not, then Randy's argument about maintenance is automatically false. > But (based on your earlier messages) you refuse to use redispatch, so > this change is not possible for you. Your proof fails when limited to > your subset of Ada, where redispatch is absent. The premise of the proof was that the operation's behavior was well-defined. Otherwise, it is already unmaintainable. Regarding use cases where re-dispatch comes in question, which certainly exist, I think that from the safety and maintenance point of view, the type system should provide means of body composition beyond simple inherit vs. override. We know, for example, that constructors (initialize) and destructors (finalize) require other means of composition. More elaborated composition tools should eliminate re-dispatch (and most class-wide operations) => give safety and maintainability. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de