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=unavailable autolearn_force=no version=3.4.4 Path: border1.nntp.dca.giganews.com!nntp.giganews.com!goblin2!goblin.stu.neva.ru!reality.xs3.de!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: 'Protected' abstract subprograms Date: Fri, 10 Jan 2014 16:30:55 -0600 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <839fee13-2743-49f6-a7f3-f95578386201@googlegroups.com> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: loke.gir.dk 1389393057 20533 69.95.181.76 (10 Jan 2014 22:30:57 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Fri, 10 Jan 2014 22:30:57 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: number.nntp.dca.giganews.com comp.lang.ada:184392 Date: 2014-01-10T16:30:55-06:00 List-Id: wrote in message news:839fee13-2743-49f6-a7f3-f95578386201@googlegroups.com... >I find it to be a fairly common occurrence and, depending on who you ask, a >programming >best practice to have a publically visible non-abstract dispatching >operation re-dispatch to >an abstract subprogram (i.e. the 'template pattern'). But Ada cannot have >abstract private >subprograms, presumably "because a nonabstract type extension declared >outside the >package would not know about any abstract primitive subprograms..." Right. Redispatching seems like a potential cause of problems, but perhaps it is OK in this case if it happens immediately (nothing else is executed). >But this doesn't really seem like the case, since A) it can already kind of >'see into' the private >part to actually extend the type and B) the private part of a child package >can *actually* see >into the private part of the parent, which is presumably where the >operation would be overridden >anyhow. C++ can have protected/private pure virtual functions, so what's >stopping Ada? You're very confused. Ada takes privacy *very* seriously, something other languages barely try. One of the Ada design's unchangable rules is that the legality of a client can never be affected by anything in the private part of tha package. (The private part can only affect the runtime behavior.) We've abandoned many good ideas over the years because of this issue -- it's the same reason that interfaces cannot be hidden. If we allowed abstract operations in the private part, then the legality of extensions would depend on the contents of the private part -- or we'd have to convert that into a runtime check rather than a compile-time one, which is the wrong direction to go. (B) is irrelevant, because Ada has no way to restrict extensions to child packages, and the problems have to be solved when extending in a non-child package -- which is the original problem of enforcing privacy. Besides, the idea of extending in child packages works if you have a small, shallow hierarchy (admittedly quite common) -- but if you have something deep (like the window hierarchy in Claw) you can't do it lest the package names get out of hand. (Note: Package use clauses are evil, IMHO, so they don't help.) >In any case, does anyone know of a workaround to achieve the same sort of >behavior? I can >always just leave both subprograms public, but that leaves an ugly scab I >just need to pick at. We never tried to do exactly what you want to do, but for Claw, we do have many implementation routines that are declared in the private part (mainly so that clients can't use them and louse things up). Those of course are not abstract, so we have a default implementation that does something, and then we override that as needed (in the private part of children, of course). Note that this pattern does not work unless you have a strictly matching hierarchy of children -- that caused us lots of trouble with Claw since we couldn't do that for reasons previously discussed. My recommendation would be to forget it and use dispatching operations directly. Moreover, one shouldn't be afraid of static binding of calls; it seems to me that someone who thinks it is a "best practice" to ensure maximum call overhead (forcing everything to dispatch even when it doesn't need to) has a problem with static binding. Randy.