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.
next prev 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