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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,2308afbbe4ecec0b X-Google-Attributes: gid103376,public From: Brian Rogoff Subject: Re: Subverting 'Access for Sub-programs Date: 1999/08/08 Message-ID: #1/1 X-Deja-AN: 510336086 References: <7ocqru$rrm$1@nnrp1.deja.com> <7oeini$1pb$1@nnrp1.deja.com> Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: nntp1.ba.best.com 934140898 209 bpr@206.184.139.136 MIME-Version: 1.0 Newsgroups: comp.lang.ada Date: 1999-08-08T00:00:00+00:00 List-Id: On Fri, 6 Aug 1999, Robert A Duff wrote: > Robert Dewar writes: > > > Well this has been dealt with in length in previous threads, > > so it is not appropriate to repeat it, but briefly, an extension > > of a tagged type with new overriding primitives clearly > > generates the possibility of dispatching to these new > > primitives. If you allow extension in a smaller scope, you > > can obviously generate dangling pointers for these methods, > > using class variables whose value is the inner derived type. > > It would thus be unsafe to allow this extension. > > Tucker and I discussed a design for allowing nested type extensions for > *limited* types, which would have prevented the dangling pointer issues. > I don't remember if we ever formally proposed this idea in public, or if > we killed it ourselves before it was seen by any reviewers. I think it > involved a lot of implementation burden, and I have vague recollections > of worrying about the mob of generic-body-sharing compiler writers we > would have had to flee from... Where have people found the inability to do nested type extensions annoying, besides cases where you're using tagged types to simulate downward funargs? I have wanted them when trying to work around the lack of downward funargs, but otherwise their omission hasn't been a big burden to me. Are there some compelling examples that I just haven't run across? I suspect that a downward funarg solution would handle most cases where a nested type extension was desired, provided the original tagged type provided for this possibility by having some primitive subprograms with access to subprogram args. > Another idea, which was never seriously considered, would be to allow > nested type extensions, and then check at run time upon leaving a scope > that there are no objects with that 'Tag still in existence. That > design could be made to work, but there are plenty of problems with it. So, only allow this for descendants of (possibly limited) Controlled types, or some similar special type? -- Brian