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!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Ada Annoyances Date: Mon, 26 Jun 2017 16:47:26 -0500 Organization: JSA Research & Innovation Message-ID: References: <1ac5a44b-4423-443a-a7bb-2864d9abe78f@googlegroups.com> <4921bd4e-3827-a7ac-7f2d-d60edbc514a3@tidorum.invalid> NNTP-Posting-Host: rrsoftware.com X-Trace: franka.jacob-sparre.dk 1498513647 928 24.196.82.226 (26 Jun 2017 21:47:27 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Mon, 26 Jun 2017 21:47:27 +0000 (UTC) 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.6157 Xref: news.eternal-september.org comp.lang.ada:47135 Date: 2017-06-26T16:47:26-05:00 List-Id: "Niklas Holsti" wrote in message news:erd8jiFhsroU1@mid.individual.net... > On 17-06-26 02:43 , Randy Brukardt wrote: ... >>> Point (b) is more difficult and I know of no work-around that can be >>> applied at analysis time. >> >> Simply banning the use of T'Class has that effect. > > At design and compilation time, yes, with consequent restrictions on the > design. But it is not a work-around that allows static analysis of > programs which do use T'Class. There's no free lunch! T'Class is by definition "indefinite", since existing code already compiled has to be able to handle newly defined types (including those that don't yet exist). That's never going to allow conventional static analysis. >> It's rather drastic, but >> it eliminates all of the dynamic features. Note that this was considered >> important enough that the standard (in Annex H) restriction No_Dispatch >> has >> this effect. >> >> You still get the other advantages of tagged types (extension, proper >> inheritance for private, equality, prefixed notation, etc.), and there is >> almost no runtime penalty (or analysis problem). > > For the application I most have in mind (a SW component currently using > discriminated records to simulate tagged types) there would be no point in > using tagged types with the No_Dispatch restriction. The loss of > class-wide programming and class-wide data structures would remove almost > all benefits. > > My hope is that a Maximum_Size aspect would let one manipulate class-wide > objects in the same "definite" way as is possible for variant records with > a default discriminant value. However, it would require that the tag of an > object could be changed by assignment; this is perhaps too radical a > change in the tagged object semantics. That seems way too drastic a change. I could imagine an aspect like the one you proposed to get rid of the indirection, but changing the semantics in a major way seems to be more than aspects are supposed to do. And changing the tag via assignment means having to be prepared to change finalization of objects after the fact as well. Ugh. Randy.