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: 103376,158ce2376534c35d X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!feeder1-2.proxad.net!proxad.net!feeder1-1.proxad.net!feeder.news-service.com!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Derived private interface Date: Sat, 23 Jul 2011 12:07:34 +0200 Organization: cbb software GmbH Message-ID: References: <27656578-65aa-48b9-9f89-4ebd4e0cb02a@glegroupsg2000goo.googlegroups.com> <0fe3b0f8-c064-444d-899d-640e891b58c3@w4g2000yqm.googlegroups.com> <128d8eb5-1cc6-47e3-a09b-b53a5ef289ce@m10g2000yqd.googlegroups.com> <4e141501$0$6629$9b4e6d93@newsspool2.arcor-online.net> <4b2728fc-6127-45d8-a314-9fc491701c26@g12g2000yqd.googlegroups.com> <82vcve4bqx.fsf@stephe-leake.org> <4e15b223$0$6541$9b4e6d93@newsspool4.arcor-online.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: ILHyZQcch+AFigDCJ5I8TA.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: g2news1.google.com comp.lang.ada:20319 Date: 2011-07-23T12:07:34+02:00 List-Id: On Sat, 23 Jul 2011 00:30:12 -0700, Jeffrey Carter wrote: > Maybe I'm missing something, but it seems to me that all dispatching in Ada is > related to extensions. Yes, but that is a language design bug (sorry, feature (:-)). There is nothing in the idea of a class of types which would instruct a derived type to add new components, and not to discard existing components, or to provide an absolutely unrelated implementation. Extension is an invention of lazy language designers. > type T2 is new T with ... > > overriding procedure P (V : in out T2); > > Then you can get a single call that sometimes calls P for T and other times P > for T2; that's dispatching. No, it always means the *same* primitive operation P defined on the type T'Class. P for T is defined on T, P for T2 is defined on T2. Neither is defined on T'Class. In Ada you always know which operation is to be called. > I don't know what dispatching means without an > extension and an overridden subprogram to dispatch to. If you mean the implementation of a primitive operation P, then how is it different from other operations? Ada separates interface and implementation. You newer know the implementation without looking into the body(es). > The equivalent of dispatching in programming by composition is a subprogram that > contains a case statement that contains calls to other subprograms. No > access-to-subprogram values involved. It does the exact same thing as > dispatching, except that it's easier to read and understand and doesn't result > in large numbers of "what am I doing wrong?" posts to c.l.a. There is a sufficient difference. The case statement needs an enumeration type (a substitute for the tag type) which should be declared in advance to all future implementations. This means that you have to know all derived types at a very early stage of the project. Certainly you don't want "others =>" in that statement. Furthermore the procedure must "with" all implementations of all derived types. Now you have: 1. Problems with maintenance (fixing the statement and with clauses) 2. You have to ensure the correspondence between the values of the enumeration type and the procedures called in "when This => That (X);". The language cannot help you here. 3. Potential problems with elaboration order (inversed, mutual dependencies). 4. Lack of static check if each "derived" type has a defined body. 5. Lack of abstract types. An abstract type has no instances, but may have implementations. I.e. it appear in the switch. But you cannot compose abstract components. Once abstract always abstract. And finally, it does not change anything semantically. Whatever problem (substitutability issues / LSP) the programmer might have with tagged types, he will under composition. > In Ada, "programming by extension" is achieved by the use of tagged types; it > includes dispatching. I have never seen anything implemented using tagged types > that could not also be implemented using programming by composition. It follows > that if there is a case where tagged types cause a problem, the equivalent > solution without tagged types is an effective work around to the problem. > > Of course, in the case where there is no solution using tagged types, there may > also be no solution without using them. An argument to Turing-completeness? (:-)) Compare: I never saw anything written in Ada, that could not be implemented in Assembler... -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de