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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.13.255.194 with SMTP id p185mr4307616ywf.205.1501959759679; Sat, 05 Aug 2017 12:02:39 -0700 (PDT) X-Received: by 10.36.26.134 with SMTP id 128mr199643iti.3.1501959759628; Sat, 05 Aug 2017 12:02:39 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!news.glorb.com!s6no667459qtc.1!news-out.google.com!196ni3210itl.0!nntp.google.com!u14no637694ita.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sat, 5 Aug 2017 12:02:39 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=76.72.190.54; posting-account=7Oy7OQoAAABhVYFOo553Cn1-AaU-bSfl NNTP-Posting-Host: 76.72.190.54 References: User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <74abc378-88a6-49bd-997b-fe25871b7303@googlegroups.com> Subject: Re: T'Interface attribute From: Eryndlia Mavourneen Injection-Date: Sat, 05 Aug 2017 19:02:39 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:47618 Date: 2017-08-05T12:02:39-07:00 List-Id: On Friday, August 4, 2017 at 7:09:19 PM UTC-5, Randy Brukardt wrote: > ... > Interfaces=20 > are only useful if there are going to be multiple implementations of them= .=20 > Otherwise, they just add unspeakable runtime overhead and you're getting= =20 > nothing for them. Specifically, you have to be able to have useful routin= es=20 > made up of only dispatching calls. When I tried that in the Claw Builder,= it=20 > turned into a maintenance nightmare - any significant change required a= =20 > change to every specific type. And adding a new specific type took multip= le=20 > days (there being so many routines to implement). It just doesn't fit wit= h=20 > the agile-style programming that I do. >=20 > >I find this kind of construction most pleasurable to design and implemen= t.=20 > >It also > >is easy to understand. >=20 > Obviously, YMMV. Just don't expect me to push for anything involving=20 > interfaces. >=20 > Randy. The whole idea is to have "multiple implementations" of the core task, tack= ing on whatever additional functions may be desired to result in different = tasks but with some shared functionality. I'm not an Ada language designer= , but my understanding is that the piecing together of tasks in this way is= handled largely by the compiler and does not *necessarily* involve dispatc= hing: type Base_Task is task interface; procedure Awaken (...) is abstract; type Random_Things is task interface; procedure Do_Random_Things is abstract; type Persistent is task interface and Base_Task; procedure Do_Something (...) is abstract; type Temp is task interface and Base_Task; procedure Do_Something_Else (...) is abstract; ... task type Persistent_Task (...) is new Common and Persistent with entry Awaken (...); entry Do_Random_Things; entry Do_Something (...); end Persistent_Task; ... This code is "off-the-cuff" and so may be a little off, but I think the int= ention is clear enough.