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!feeder.eternal-september.org!news.unit0.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: Ada Successor Language Date: Tue, 26 Jun 2018 23:49:26 +0300 Organization: Tidorum Ltd Message-ID: References: <5e86db65-84b9-4b5b-9aea-427a658b5ae7@googlegroups.com> <878t7u1cfm.fsf@nightsong.com> <776f3645-ed0c-4118-9b4d-21660e3bba4b@googlegroups.com> <87602fbu2g.fsf@nightsong.com> <87po0mziqt.fsf@nightsong.com> <87fu1izfgs.fsf@nightsong.com> <878t75nwad.fsf@adaheads.home> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: individual.net DUKlgVKk5yP/aD6m2PlrWwD9lBhVh6V5PRNHeOCw/kt0uCzRXq Cancel-Lock: sha1:E5B7w6nj0l+LfqHT8BCUF+LNV9E= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 In-Reply-To: Xref: reader02.eternal-september.org comp.lang.ada:53350 Date: 2018-06-26T23:49:26+03:00 List-Id: On 18-06-26 23:16 , J-P. Rosen wrote: > Le 25/06/2018 à 16:03, Niklas Holsti a écrit : >> So it says in RM 3.4(5/2), but even the Annotated RM has no motivation >> for it, and I don't see why Ada could not assume a null extension when >> the type is tagged. Can someone explain why the RM is so strict on this? >> >> (In fact, it seems to me that Ada could allow untagged record extensions >> as well; the effect would be the same as for tagged ones, but no 'Class >> would be formed, and no class-wide programming or dynamic dispatch could >> be used, so all such types would be static. It would be semantically >> equivalent to aggregation of a component of the parent type with the >> extension components, but would allow direct access to the inherited >> components from the parent type. This could be a useful separation of >> extensions from tags.) > You can achieve exactly this with a tagged type and Restriction > (No_Dispatch) Not exactly that, no: you would still have to declare the types as tagged, and the objects of these types would still have to store the tag value somewhere, at least for use when X'Tag is taken for a controlling parameter X of an inherited (non-overridden) operation. Moreover, Restriction (No_Dispatch) is partition-wide (or so I believe, because "tailored" run-time systems are mentioned in that part of the RM, H.4). Thus it would not let one use both tagged record extensions and untagged record extensions in the same program partition. In fact the only similarity I can see between Restriction (No_Dispatch) and the suggested extensibility of non-tagged records is that the latter (as I suggested it) would also not allow dispatching -- but preventing dispatch was not the point of the suggestion. Combining extension of untagged records with Dmitry's suggestion for untagged class-wide types would allow dispatch (but not re-dispatch) for such extensions, which IMO shows that Restriction (No_Dispatch) is independent of untagged record extensions. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .