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: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!gandalf.srv.welterde.de!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Task interface and entries with aliased parameters Date: Wed, 28 Oct 2015 17:23:08 -0500 Organization: JSA Research & Innovation Message-ID: References: <98fcf225-fdec-401c-80b3-321e2ac65f6b@googlegroups.com><1e09jksdqcfyv.8f80k06gl5ye$.dlg@40tude.net> <87lham3hyu.fsf@theworld.com> NNTP-Posting-Host: rrsoftware.com X-Trace: loke.gir.dk 1446070989 3012 24.196.82.226 (28 Oct 2015 22:23:09 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Wed, 28 Oct 2015 22:23:09 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-RFC2646: Format=Flowed; Original Xref: news.eternal-september.org comp.lang.ada:28103 Date: 2015-10-28T17:23:08-05:00 List-Id: "Bob Duff" wrote in message news:87lham3hyu.fsf@theworld.com... > "Randy Brukardt" writes: > >> Sharing interfaces *sounds* nice, but it's impossible in practice because >> in >> almost all circumstances you need parameters of different types for >> different "instances" ("instances" not in the Ada sense). Think container >> interfaces, for example - the element type is almost always different. > > Different from what? Maybe you could show some code that illustrates > your point. Backing up a bit: an "interface" is just a type and its operations (primitive operations in Ada jargon). An interface (Ada term) just gives a single name to that set. The problem is, that it is rare that you have more than one "interface" in a program (or library, or anything) where the operations all have the same parameter profiles. A container (say a map) is an example. A map interface sounds useful and attractive, but it's an illusion. Many of the operations of a map have parameters of the element type. And those are likely to be different, unrelated types. (Indeed, if your compiler doesn't share generic bodies, it's almost guaranteed as you'll want to have all containers with a particular element type share an instance in order to avoid code bloat -- in which case there would never be a use for an interface.) The only way for such a map interface to be useful is to have one for some related hierarchy of types. But that either forces all the type checking to runtime (since the interface can only take Root'Class), or some sort of co-derivation scheme (not part of Ada) in order to derive multiple types in lock-step. (I've tried to figure out how to make such a scheme work in Ada terms, but I've failed; you get weird situations of inherited routines where the types don't work out.) You could also put such an interface into a generic to parameterize the different types, but that doesn't buy you anything over using a similar generic directly. I could see how interfaces might make some sense in a language where everything is descended from a single type (Object in Java), but Ada is far away from that. Thus, I put Ada interfaces with the group of mistaken features in Ada: anonymous access types, coextensions, interfaces. I fault myself in part for those mistakes, because I didn't recognize how truely useless (and even damaging) these things would turn out to be. Randy.