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.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 Path: border1.nntp.dca.giganews.com!nntp.giganews.com!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!feeder.erje.net!eu.feeder.erje.net!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Natasha Kerensikova Newsgroups: comp.lang.ada Subject: Re: Your wish list for Ada 202X Date: Wed, 16 Apr 2014 07:24:37 +0000 (UTC) Organization: A noiseless patient Spider 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> <1wjmcbk375lzk.6o7dpqcp3va3.dlg@40tude.net> Injection-Date: Wed, 16 Apr 2014 07:24:37 +0000 (UTC) Injection-Info: mx05.eternal-september.org; posting-host="76a49b86bc3e16725b7cfca3d85cb4c8"; logging-data="6432"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX184LO0N7yFs5KPsEH+sW1d3" User-Agent: slrn/1.0.1 (FreeBSD) Cancel-Lock: sha1:nWXpTY8URsFfrP/Nh71Kc4uggho= Xref: number.nntp.dca.giganews.com comp.lang.ada:185764 Date: 2014-04-16T07:24:37+00:00 List-Id: Hello, On 2014-04-16, Niklas Holsti wrote: > On 14-04-15 10:21 , Natasha Kerensikova wrote: >> I've always thought of this as "re-disatching". Is it? > > Yes, as I understand the word. > >> Are there better language facilities to use in such situations? > > If, as you say above, descendants of T are supposed to inherit the > primitive operations of T *without overriding them*, you could implement > those primitive operations instead as class-wide operations (operations > on T'Class), and then calls of AO from those class-wide operations would > be (simply) dispatching, and not re-dispatching. > > As I understand them, both Dmitry and Randy would consider the > class-wide form a better solution, but it works only if you never need > to override these class-wide operations for any descendant types. > > I am seldom sure about that (never needing to override, not even in the > future), so I prefer to have the operations as primitive rather than > class-wide, and consequently to use re-dispatch. Indeed, I can make the whole algorithm class-wide, I had completely missed the possibility. In the few cases of such redispatching I encountered recently, it makes sense to actively prevent the non-abstract operations from being overridden, because they really need some kind of internal consistency, so you would either override all of them or none. If you would override them all, you can just build a new type with the same interface and use composition. However it turns out that in those cases I actually can't make them class-wide, because those operations are part of an interface publicly implemented by the abstract type. And even if you think of interfaces as evil, it seems the same problem would arise with a purely abstract parent. Is there a technical reason to forbid abstract operations from being implemented by a class-wide operation on a descendant type, and thereby being shared rather than inherited for the whole subtree? Natasha