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: Robert A Duff Subject: Re: Subverting 'Access for Sub-programs Date: 1999/08/06 Message-ID: #1/1 X-Deja-AN: 509586558 Sender: bobduff@world.std.com (Robert A Duff) References: <7ocqru$rrm$1@nnrp1.deja.com> <7oeini$1pb$1@nnrp1.deja.com> Organization: The World Public Access UNIX, Brookline, MA Newsgroups: comp.lang.ada Date: 1999-08-06T00:00:00+00:00 List-Id: 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... 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. - Bob -- Change robert to bob to get my real email address. Sorry.