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!news.eternal-september.org!feeder.eternal-september.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!newsfeed.xs3.de!io.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: T'Interface attribute Date: Wed, 2 Aug 2017 23:46:53 -0500 Organization: JSA Research & Innovation Message-ID: References: Injection-Date: Thu, 3 Aug 2017 04:46:54 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="27696"; mail-complaints-to="news@jacob-sparre.dk" X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 Xref: news.eternal-september.org comp.lang.ada:47566 Date: 2017-08-02T23:46:53-05:00 List-Id: "Dmitry A. Kazakov" wrote in message news:olskua$1bfd$1@gioia.aioe.org... > In order to reduce name space contamination I would propose attribute > T'Interface which for any tagged type T would denote an interface type > with all *new* primitive operations, e.g. Past experience say that such attributes (that is, those that designate some sort of type or subtype) don't work out very well in Ada. For instance, we considered T'Access in Ada 2005, but gave that up because of various problems (and replaced with with anonymous access types, which are worse). The worst problem was that there was no limit to the attribute, you could write T'Access'Access'Access - and you can't prevent this since T could be a generic formal type that itself is some T'Access. Almost all Ada compilers materialize all Ada types in their symbol table, so the effect of having a T'Interface would be that it would be automatically declared for all tagged type declarations. Most Ada compilers also materialize all of the primitive operations in their symbol table, so there would be a large increase in memory usage and some time increase (all lookups would have twice as many primitives to look through). All that said, it may make sense to work out the details; clearly an interface (which is indefinite) has less of these issues than an elementary type like T'Access. But I'm certain that it would have a distributed overhead on a compiler (maybe not as much of a concern as a distributed overhead on a compiled program, but it still matters). Randy. P.S. And as always, explain the problem to be solved as well as the possible solution. That is always necessary to understand the value of a proposal. P.P.S. I personally have never seen a real-world example where an interface actually helps. There's lots and lots of book examples and show examples and so on, but in practice you end up with only a single implementation so there really is nothing gained by involving a lot of dispatching calls. Ergo, I'm against anything (new) involving interfaces. YMMV.