comp.lang.ada
 help / color / mirror / Atom feed
From: "Randy Brukardt" <randy@rrsoftware.com>
Subject: Re: T'Interface attribute
Date: Wed, 2 Aug 2017 23:46:53 -0500
Date: 2017-08-02T23:46:53-05:00	[thread overview]
Message-ID: <olu9ru$r1g$1@franka.jacob-sparre.dk> (raw)
In-Reply-To: olskua$1bfd$1@gioia.aioe.org

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> 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. 


  parent reply	other threads:[~2017-08-03  4:46 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-02 13:43 T'Interface attribute Dmitry A. Kazakov
2017-08-02 14:23 ` Eryndlia Mavourneen
2017-08-03 12:52   ` Dmitry A. Kazakov
2017-08-03  4:46 ` Randy Brukardt [this message]
2017-08-03  7:26   ` Dmitry A. Kazakov
2017-08-04 23:51     ` Randy Brukardt
2017-08-05  7:49       ` Dmitry A. Kazakov
2017-08-07 22:59         ` Randy Brukardt
2017-08-08  6:13           ` Dmitry A. Kazakov
2017-08-09  0:38             ` Randy Brukardt
2017-08-09  7:06               ` Dmitry A. Kazakov
2017-08-09 23:03                 ` Randy Brukardt
2017-08-10  7:13                   ` Dmitry A. Kazakov
2017-08-11  0:33                     ` Randy Brukardt
2017-08-11  6:55                       ` Dmitry A. Kazakov
2017-08-11 20:49                         ` Randy Brukardt
2017-08-03 17:27   ` Eryndlia Mavourneen
2017-08-05  0:09     ` Randy Brukardt
2017-08-05 19:02       ` Eryndlia Mavourneen
2017-08-07 22:49         ` Randy Brukardt
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox